jsnext:main directory support?

[robwormald]

This isn't strictly node resolution, but I figure this is as close a place as any.

Situation:

Angular2's codebase distributes es modules in a subdirectory /esm and denotes the jsnext:main field in the package.json.

This works well, except for our compiler-generated code outputs code that uses deep imports (which is a much longer story...), so whereas most userland code does stuff like:

import {Component} from '@angular/core'

which resolves fine via jsnext:main and this plugin, our generated code does stuff like

import {ViewFactory} from '@angular/core/src/some/deep/path'

which of course fails to resolve properly. I implemented a simple plugin that did a path rewrite, but that seems to confuse rollup's symbol resolution, so I end up with multiple copies of imports, which breaks all kinds of things. None of this is particularly unexpected.

On a whim, I dug into the source of this plugin today and moved my dirty hack into the _resolveId function, leveraging path-resolve's pathFilter function to rewrite the path internally, relative to the jsnext:main file, and lo and behold my issue is solved.

Would a PR be accepted to enable this behavior? Or should this already work? Or is it out of scope of this plugin?

tldr: basically, i want to leverage jsnext:main to rewrite all imports into a package relative to the es module main entry point, rather than just the main.

[robwormald]

cc @IgorMinar

[IgorMinar]

the other option would be to support .mjs but that will require changes throughout the whole ecosystem.

[Victorystick]

@robwormald As this plugin can be configured to resolve ids according to the browser field in package.json (initially Browserify specific, which isn't strictly Node behavior) I'm not sure what to consider out of scope for this plugin.

If it's a small change which will be useful also outside of Angular, go ahead and create a PR. I'm assuming it'd be useful for other users of scoped packages. 👍

@IgorMinar Supporting a proper standard, be it .mjs or something similar, is the end goal. But I think it's more important to roll out something that solves the Angular use-case first.

[IgorMinar]

browser field just specifies an alternative entry point for a different environment.

our problem is that we have a quite hard requirement to support deep imports for various environments, so not only we are trying to support cjs and esm builds but also we want need to support imports from package-name and package-name/some/path.

[TrySound]

Is this still relevant?

[fregante]

jsnext:main is deprecated and module won't support that. Sorry 😅

Perhaps .mjs will essentially fix this, if that ever materialize and the developers support it.