How to configure source maps generated by babel?

>The *.js.map files are right next to the *.js files (and idea seems to see them as they are nested in the file tree)

it means nothing - files are grouped by name. Patterns can be configured in Project tool window options (under the gear icon), "File nesting"

>But navigation still goes to the derived files.

Please can you elaborate on this? What are derived files?

Note that WebStorm doesn't (and never will) use sourcemaps for types hinting/navigation. Sourcemaps are ONLY used by debugger

index.js // es6
src/foo.js // es6 

dist/index.js // compiled by babel
dist/src/foo.js // compiled by babel
dist/src/foo.js.map // sourcemap created by babel

package.json: 
  ...
  main: "dist/index.js"

And yes, I do want idea to use the source map for navigation and such, not just for debugging. Is it a technical reason not to support source maps, lots of other IDEs are happy with them? 

If _never_ is _never_, I guess I will have to not pre-compile node node modules before pushing to repository and leave it to end application to do the babel transform on the fly.

>And yes, I do want idea to use the source map for navigation and such, not just for debugging.

please can you clarify what you mean? Right now, if both ES6 and generated .js files exist in the project, WebStorm normally uses the former for navigation/types resolving, and it doesn't need sourcemaps for this.

This is for modules reference in package.json, not the files directly contained in the idea project. The depended on module has been pre-processed by babel down to what nodejs can run, where the processed files are in the dist/ directory from above. Then in idea when I use that model and navigate to its functions idea follows the 'main' in the package.json, which in this case would be dist/index.js.

And here is where the sourcemaps come in (for the module in package.json, not the code directly in the idea project): 

dist/index.js
dist/index.js.map // this points to ../index.js, but idea does not follow that reference

...

btw, I am pre "compiling" the ES6 to nodejs' level because I have some older javascripts projects that need to use these modules.So I can't really rely on the using project to run babel at runtime. 

adding "jsnext:main":"path/to/your/ES6 main file" to library package.json should help - WebStorm will be using this file instead of "main"

Very nice! That seems to work for the first level of indirection, but not the second level. (ie, when module depends on another module). But I'm using 'npm link' to test. I'll rebuild and publish and see how that goes. 

Even so, this is an excellent solution. Thanks very very much Elena.

I'm sure I understand perfectly what was meant by the original poser.
Suppose I have `src/` and `dist/` directory in my library. Where in the src/ I have JSX source and in `dist/` the transpiled code with .map for each file.
And I use "Go To Declaration" command in my App.js file what I expect is for WebStorm to open the original source code in `src/` and notthe transpiled mess in `dist/`
What should I do?

please read the comments above. Sourcemaps are only used for debugging, not for types resolving/navigation. And the IDE normally prefers original files to transpiled ones (it's has always been recommended, BTW, to exclude the dist folder from indexing for better performance and navigation)

The `dist/` is excluded. Navigation still uses it every time. Obviously because `dist/` is marked as { "module": "./dist/index.js" } in package.json

Yes, exactly - when navigating to libraries (node_modules) the IDE uses main, module, etc. fields when looking for modules. And the module field has a highest priority as it is more likely to become a standard. Please see webpack and rollup docs - both suggest using module to point to a script that utilizes ES2015 module syntax.

Okay. Found it.

// eslint-disable-next-line no-undef
System.config({
  paths: {
    'myLib': '../myLib/src/index.js',
  },
})

Obviously I'm using rollup with "module" for the compiled sources.
All the libraries are ESM anyway. I'm trying to solve the JSX problem, I've already solved the ESM one.

Elena,

> please read the comments above. Sourcemaps are only used for debugging,
> not for types resolving/navigation. And the IDE normally prefers original files
> to transpiled ones (it's has always been recommended, BTW, to exclude the
> dist folder from indexing for better performance and navigation)

But when a stacktrace is generated and displayed in the Webstorm console, clicking on a line takes you to the transpiled ones, NOT the source. 

I opened an issue: https://youtrack.jetbrains.com/issue/WEB-44801

Hello,
I need to touch this subject again.

As for solution mentioned here https://intellij-support.jetbrains.com/hc/en-us/community/posts/115000562724/comments/360001377140
Quick explanation why it is not wanted solution: The 'module' field is taken as raw code while compiling by Webpack. As we are talking about already transpiled code which is usually provided by Vendors as UMD libs, so that consumers can exclude /node_modules/ from babel-loader which is required for bundling performance. This kind of resolution is highly unwanted in cases of already transpiled libs (most cases)

Solution mentioned here https://intellij-support.jetbrains.com/hc/en-us/community/posts/115000562724/comments/115000486210
partially works, but again we are talking about Vendor's libs that don't necessarily need to contain this field especially it is not a field documented in package.json specification https://github.com/SchemaStore/schemastore/blob/master/src/schemas/json/package.json. Though we have official esnext (https://github.com/SchemaStore/schemastore/blob/master/src/schemas/json/package.json#L611) field which actually works same as 'jsnext:main', The problem is that this esnext field is mostly not populated by Vendors :/

It would be really nice if module resolver would follow the source maps as references for source code. Currently the only workaround to me is to use https://www.npmjs.com/package/patch-package to add esnext field to vendors packages. However using this field for Typescript sources is confused, due to the fact in most cases 'typing/types' fields lead IDE to declarations only even declarations maps and sources are in place :/