I have an error in Webstorm when using ES6 named import declaration:

import { nodes } from 'utils/dom';

I get "cannot resolve symbol" error on "nodes"

Also when I try to export as named export like this:

export {
  write: document.write.bind(document),
  node: document.querySelector.bind(document),
  nodes: document.querySelectorAll.bind(document)
};

I get errors too. I use eslint with babel-eslint parser. The thing is that this works in Sublime Text 3 as a charm, but for some reason fails error checking in Webstorm.

I assume that this is because except Eslint webstorm is doing other code checking.

Any Idea how I can suppress that and use only eslint with babel-eslint parser?

Any advice will be appreciated

I have an error in Webstorm when using ES6 named import declaration:

import { nodes } from 'utils/dom';

I get "cannot resolve symbol" error on "nodes"

Also when I try to export as named export like this:

export {
  write: document.write.bind(document),
  node: document.querySelector.bind(document),
  nodes: document.querySelectorAll.bind(document)
};

I get errors too. I use eslint with babel-eslint parser. The thing is that this works in Sublime Text 3 as a charm, but for some reason fails error checking in Webstorm.

I assume that this is because except Eslint webstorm is doing other code checking.

Any Idea how I can suppress that and use only eslint with babel-eslint parser?

Any advice will be appreciated

• javascript
• frontend
• webstorm
• ecmascript-6
• babeljs

• Your export is just wrong, that's not how exports work. Not sure for the import though. What is utils in this case? That's not a standard path, since it is not a relative file path. Do you have custom module resolution logic somewhere? – loganfsmyth Commented Jul 25, 2015 at 18:02
• Well you can export object and then import { property } from 'path' local variable property will be assigned with the value of exported property. Nothing wrong with the syntax. It works just fine. It does not supposed to be relative file path. I use webpack and babel loader. I don't need relative file path since I use moduleDirectories in webpack config to search in set of folders. So bottom line is that it works. And it's correct the question is why webstorm shows it as incorrect – Vladimir Novick Commented Jul 25, 2015 at 20:27
• @VladimirNovick How did you solve this problem then? – smilingpoplar Commented Jan 22, 2016 at 12:27

2 Answers 2

I get "cannot resolve symbol" error on "nodes"

is because utils/dom in standard Node code means "find dom.js inside a module called 'utils'. You have overridden this behavior by using webpack's moduleDirectories property, but WebStorm doesn't know what that is. For WebStorm to properly resolve utils/dom, you'll need to add the utils folder as a library in your webstorm project configuration.

Your export syntax is incorrect. ES6 import/export syntax is 100% unrelated to objects, and in your example export, you are using object syntax. import { nodes } is asking for an export named nodes. There are multiple ways that you could write the exports that you have:

export const write = document.write.bind(document);
export const node = document.querySelector.bind(document);
export const nodes = document.querySelectorAll.bind(document);

or alternatively you could collapse them if you like multiline var/let/const

export const write = document.write.bind(document),
    node = document.querySelector.bind(document),
    nodes = document.querySelectorAll.bind(document);

or even

const write = document.write.bind(document);
const node = document.querySelector.bind(document);
const nodes = document.querySelectorAll.bind(document);


export {write, node, nodes};

Hard to say if this is directly related, but for Webstorm to know how to resolve your imports, you can also go to Preferences > Directories and set folders as Resource Root (or right/context-click on a folder and set it that way)

This might need to be done, for example, when you've configured Webpack to resolve certain sub-directories, where your project structure might be:

/
  /docs
  /src
    /containers
      /app
        App.js
    /components
      /header
        Header.js

In which case Webstorm would expect an import in App.js to look like the following:

import Header from '../../../components/header/Header'

Whereas with Webpack, if you've added src as a module to resolve, you can do the following, which Webstorm doesn't currently understand, hence adding it as a Resource Root resolves the issue

import Header from 'components/header/Header'

Reference: Path aliases for imports in Webstorm