1. withInfo and withConsole modules: with Flow enabled, Webstorm uses type definitions from flow-typed when resolving types ... And both flow-typed/npm/@storybook/addon-info_vx.x.x.js and flow-typed/npm/@storybook/addon-console_vx.x.x.js are auto-generated files that don't include stubs for corresponding modules. If you change the project Javascript language version to ECMAScript 6, modules will be correctly resolved to definitions in node_modules/@storybook/addon-info/src/index.js, etc.
2. what is require.context()? it's not a part of Node.js core. Webpack method?
require.context() is a webpack thing, but it is not really a method, more like a directive. During build whenever webpack finds a `require.context()` it internally understands as actual `require` statements for each file matching the criteria defined for the context (starting folder to look in, include subfolders or not, and a RegEx pattern to match the files).
So in fact it is not only JS. It gets executed as JS and returns the list of files, but at the same time it is an automation tool built into webpack to dynamically `require` files during build.
So as far as "normal" JS goes, it may be right from the perspective of WebStorm to mark it as an unresolved function or method, because really it is not "only" a method.
Still, support and deeper understanding of such directive would be nice, but that goes beyond interpreting it as a regular JS expression.
Can't recreate using similar settings in 2018.3.3 - I'm not prompted to import Promise from q library regardless of JavaScript language settings:
what IDE version do you use? Can you share a sample project that can be used to recreate the issue?
thanks
I guess the problem was here...
as soon as I unchecked this checkbox the notification disappeared
But I can't recreate the issue with node_modules included in index...
v. 2018.3.2
I'll make a repo with empty project but all packages tomorrow.
https://github.com/kherel/webstorm-question-1
there are severals errors:
But it used it in pages/index.js
This is the next.js method and I've added next.js types as a library. (maybe I didn't understand how it works)
1. withInfo and withConsole modules: with Flow enabled, Webstorm uses type definitions from flow-typed when resolving types ... And both flow-typed/npm/@storybook/addon-info_vx.x.x.js and flow-typed/npm/@storybook/addon-console_vx.x.x.js are auto-generated files that don't include stubs for corresponding modules. If you change the project Javascript language version to ECMAScript 6, modules will be correctly resolved to definitions in node_modules/@storybook/addon-info/src/index.js, etc.
2. what is require.context()? it's not a part of Node.js core. Webpack method?
3. Promise: reproduced, logged as https://youtrack.jetbrains.com/issue/WEB-36906
Don't know about point 2, probably it's a part of storybook addons.
Got it about points 1 and 3.
What to do with "unused default export", for next.js files? Is it possible to desable this check for specific folder?
You can suppress this warning for statement, like:
It's also possible to disable all JavaScript | General | Unused global symbol warnings for specific folder:
See https://www.jetbrains.com/help/webstorm/2018.3/inspections-settings.html#5, https://www.jetbrains.com/help/webstorm/2018.3/configuring-inspection-for-different-scopes.html
Regarding point 2.:
require.context() is a webpack thing, but it is not really a method, more like a directive. During build whenever webpack finds a `require.context()` it internally understands as actual `require` statements for each file matching the criteria defined for the context (starting folder to look in, include subfolders or not, and a RegEx pattern to match the files).
So in fact it is not only JS. It gets executed as JS and returns the list of files, but at the same time it is an automation tool built into webpack to dynamically `require` files during build.
So as far as "normal" JS goes, it may be right from the perspective of WebStorm to mark it as an unresolved function or method, because really it is not "only" a method.
Still, support and deeper understanding of such directive would be nice, but that goes beyond interpreting it as a regular JS expression.