JavaScript Libraries Improvements in WebStorm 6

Every JavaScript project bigger than “Hello, World” one uses libraries, often many of them. That’s why handling libraries properly is so important for the IDE. Let’s look at how WebStorm 6 supports libraries and what have been changed since version 5.

If you haven’t played with libraries lately, or just want to refresh memory, please take a look at our previous posts. And you can try all this in the recent WebStorm release.

  • WebStorm brings you JavaScript definitions (aka “stubs”) for the standard DOM, HTML5 and EcmaScript API, as well as for Node.js global objects, via co-called “predefined” libraries. We’ve simplified this list, so now it’s going to be clear what to enable depending on your target environment:
  • There’s often a situation when you have a release (minified) version of the library file along with, or instead of the debug (source) one. Minified version is not only unpleasant to read, it’s also quite complicated for the IDE to handle. That’s why we recommend to always have debug version on hand. Accordingly, the IDE will automatically detect and ignore minified files, picking up the definitions and documentation from the debug version:

    If there’s no debug version available, the IDE will use release version for completion and symbols resolution, but will refuse to navigate to the obfuscated file.
  • Enabled libraries now affect not only the completion list, but also the highlighting. This means that function defined in the library that is not enabled for the file will be red-highlighted in the editor (and, sure, missing in completion list in this file).
  • All the library files are now write-protected and by default are not checked for errors. They are no more part of refactoring scope, so you don’t need to worry if your rename will accidentally change something in the library that you use. If you’re using File Watchers the IDE will put generated files in the library, this way keeping them from direct modification.
  • You can fine-tune the list of available libraries for a certain folder or file via “Manage scopes” dialog. This way you can e.g. keep your server and client-side code in the same project. To quickly remember which libs are in scope for the current file you just need to click the Hector icon icon located in the bottom-right on status bar:

We have a lot of ideas how to make tweaking libraries even easier. If you’ve got your thoughts on this, or feel something should have been done differently please share your opinion in the forum and bug tracker. Your feedback will help WebStorm become even better! :-)

Develop with pleasure!
– JetBrains WebStorm Team

This blog is permanently closed.

For up-to-date information please follow to corresponding WebStorm blog or PhpStorm blog.

This entry was posted in Cool Feature, WebStorm and tagged , . Bookmark the permalink.

11 Responses to JavaScript Libraries Improvements in WebStorm 6

  1. Sebastiaan van Stijn says:

    “All the library files are now write-protected”

    Please, add an indication / message that the file is write-protected. Although there’s a different icon for library-files, but it’s very confusing from a UX perspective when you try to type in a file and nothing happens. And the IDE does not give a message ‘why’ you’re not able to.

    I’d suggest adding a ‘banner’ at the top of the editor, explaining that it’s a library file and therefore write-protected, and a link to the right section in the settings so that this can be modified.

  2. Hopefully this one will make it to v6 release: It is really essential for Node.js development.

  3. Guenter says:

    its still slow as before. Please add an option to exclude folders from the indexer, preferably with regexes, or folder wildcard names. In large projects (with custom dojo builds) it takes 5-10 minutes that you can proceed with working and we’re really have the latest top notch hardware from the market(64GB RAM, SSD in raids).

    What’s also still missing : templates for custom doc styles.

    Thank you.

    • ksafonov says:

      Thanks Guenter,

      > its still slow as before
      Please take CPU snapsot:

      > templates for custom doc styles
      Do you mean JSDoc? Can you bring an example?

      > need to have global deployment configs across projects
      But every project has it’s own paths? How would mappings be valid for different projects?

      > ability to run multiple deployments when the auto-deployment is on
      Please vote for

      > Another really needed feature is to drag tabs into layout zones like in eclipse.
      Please submit new request in tracker (via link above)

  4. Guenter says:

    ah, fully forgot to mention that there is really a need to have global deployment configs across projects, and the ability to run multiple deployments when the auto-deployment is on.

    Another really needed feature is to drag tabs into layout zones like in eclipse. Especially the debugger panel needs improvements as it takes up 50% of the screen height when using it.

  5. Guenter says:

    thank you,
    so I voted for user and ide variables from/within the deployment config editor, thus sharing/replacing any sort of settings across projects.

    regarding the doc style templates, please have a look in Sparx-Enterprise-Architect, ie.: code generation.

    There many problems with JSDoc out of the box. A simple template editor would be awesome and allow wiki-style comments to the code. See also Dojo’s comment syntax.

    Thanks again.

    • ksafonov says:

      > A simple template editor would be awesome and allow wiki-style comments to the code.
      Could you please submit a feature request and give an example?

  6. Does it support ExtJS?

Comments are closed.