'import from' doesn't work as well as 'require' for autocompletion and 'go to declaration'

Logged as https://youtrack.jetbrains.com/issue/WEB-17119, please vote for it to be notified on any progress

I'm failing to see how that was related to this issue.
Imports are not auto completing for me under webstorm 11 which that issue was marked fixed for.
require auto completes fine.

Is there anyone else having this issue or a way to get it working?

question over at SO
http://stackoverflow.com/questions/33589798/webstorm-11-no-autocompletion-on-es6-import-statements-vs-node-require

I'm also experiencing the issue that Siggi Orn reports. Using the 'import' syntax of ES2015, WebStorm just fails to have an idea as to where the declaration is. This works like a charm:

const d3_scale = require('d3-scale')

This however fails to navigate to the declaration:

import d3_scale from 'd3-scale'

when I try to navigate to

d3_scale.linear()   // I underscored what I try to navigate to

In fact, the list dialog offered is rather useless, because it doesn't show the node module of the various alternative definitions; instead, it's just a random list with '(node_modules)' indicated as the source. Also, it offers declarations that I can't / don't want to use anyway, such as jQuery, which I avoid on new projects - just because it might be a dependency to some devDependency I might use, it's irrelevant as the project can't and doesn't want to access dependencies of dependencies.



The analogous issue is present with code completion too.

I was about to upgrade to a WS11 license as it was suggested that it fixes it, but testing it on a 30min trial version, the issue is still present with WS11. I'm eagerly awaiting a version which does as good a job with the standardized module notation as with the legacy notations. React in general is well-supported by WebStorm (JSX etc), however most modern broilerplates etc. use ES2015 module notation and it's good practice to follow the standard anyway.

Btw. spent a good hour on narrowing down to this issue and then finding a relevant thread (this one), as one of my projects was navigable and another wasn't, and there were numerous differences such as ES6 vs JSX Harmony etc.

Glad to see someone giving feedback on the issue.
From the ticket I created; they claim to have fixed it in "webstorm 12". I guess we'll see..

https://youtrack.jetbrains.com/issueMobile/WEB-18989

Thanks Brett, awesome, both the ticket you created, and the commitment from the great JetBrains team!

Yes I was wondering how it wasn't a more prominent issue as people flock to ES2016, Babel, React and/or Webpack tooling in droves - which have generally been well-supported by WebStorm for a good while - and this is bound to come up.

Just looked it up... apparently available as an EAP, I'll check out this one :-) https://confluence.jetbrains.com/display/WI/WebStorm+EAP

Oh awesome! Post back you're findings if you could. I won't be near my office computer for another week to check it out myself.

Looks improved! Now the 'import' syntax works, but not consistently (depends on library, and apparently, state: maybe it's a reindexing issue). For example, Ramda is OK:

But d3_scale is not always OK (though sometimes it was OK):

It may be an exports vs module.exports issue in Ramda vs d3_scale, I don't know.

A piece of good news is that this version properly shows if an import became unused in a given module, see webgl in grey (WS10 shows it just like the others):

Interestingly, this only works with the old require notation. If I switch some to import, there'll be no indication that the module is unused, no greying; webgl and filter look identical:


So all in all, definite, useful improvements, but it's an EAP, so it probably hasn't gotten all the testing and stability yet.

Robert

Awesome. Thanks for the updated info.
One thing I'm curious if you go into settings >> language settings >> JavaScript >> switch the drop down to es6 and check both "prefer strict" and "only type based suggestions" does the auto completion portion become useless on imports for node modules?

Didn't seem to make a difference, although no reindexing took place, so I don't know if it's a caching thing or not. The problem is, these symbol completion and declaration navigation features aren't like absolute show-stoppers, which is why they can be less reliable or less demanding (no specific quality standards exist) but I find these very useful. Refactoring support and declaration lookup across modules are the two main things as to why I prefer to use an 'intelligent' IDE, and both these require proper cross-referencing of the application - not including everything but the kitchen sink, but including those modules I'm directly(!) using on the project.

Speaking of refactoring, in WS10 the file name refactoring is broken: changing a file name didn't cause the corresponding change in import / require references. It still doesn't work in WS12. It's an unrelated issue but in the loose family of smart (i.e. code structure aware, not just syntax aware) editor features.

... btw. rename refactoring of exported symbols, e.g. from module.exports = {foo} to module.exports = {bar} are also just local in WS12, even if there are clear references to these exports elsewhere (i.e. no name changes in the user code)

Interesting. And I totally agree with you. The auto complete menu in your screenshot showing "(several definitions)" is what has been bugging me the most. These are the only set of IDEs that make me enjoy php and JavaScript as if I'm writing c# in visual studio or java in eclipse.

The Ramda 'several definitions' isn't  bad; one definition jumps you to the export, and the other, more usefully, to the actual definition (i.e. makes two jumps for you). There's even some iconic difference between them though it's an acquired taste to memorize signs like this (no hover-on document or anything):



I guess it's a lucky accident that there is only one Ramda in the node package tree. It should only offer, or prioritize, showing directly referenced, i.e. scope-wise accessible packages (relative to wherever I am in the package tree).
Though I'd prefer 'ramda' instead of 'node-modules' as the former is informative (as it's common to have meaningless entries and I can't memorize which packages work or don't work for symbol completion) while the latter isn't (everything in a modern web app is in node modules). Again, not bad in the present case for Ramda.

But the 'several definitions' and other bogus entries for d3_shape or flyd make this feature rather useless. You may be luckier with your libraries.

Wanted to mention about the awesomeness which is, when you refactor the file structure of your application, e.g. drop files (ES2015 modules) from one directory to another, it'll update all dependencies. It's hugely useful to restructure with low cost, because then one is encouraged to constantly strive for cleaner structure, no reservations like ... eh 'I'd need to chase down references and update them'. Btw. I also like the F5 key for duplicating the current file; makes it easy to first separate self-contained parts, then divide them to two files.