Preset's name for scoped packages

[artola]

I have presets for all the parts in the tool-chain, from Jest to TSLint. Then I did the same for Babel.
The preset works perfectly, if the name is "babel-preset-xxx", but we prefix all our react stuff then the package become "@company/rdk.babel-preset-xxx".

Now if I try to use it in webpack as:

          {
            loader: 'babel-loader',
            options: {
              presets: ['@company/rdk.babel-preset-xxx'],
            },
          },

THIS BREAKS :( ... with this message:

Error: Cannot find module '@company/babel-preset-rdk.babel-preset-xxx' from ...
- If you want to resolve "@company/rdk.babel-preset-xxx", use "module:@company/rdk.babel-preset-xxx"

As the hint says, prefixing with module: works. But also just suffixing with /. I mean, both options works:
presets: ['module:@company/rdk.babel-preset-xxx'] and/or presets: ['@company/rdk.babel-preset-xxx/']

Is this documented in some place? Could be possible scoped packages different than @babel/ to be resolved using node resolution before Babel's resolution ?

[babel-bot]

Hey @artola! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

[xtuc]

Please indicate the version of Babel you are using.

[loganfsmyth]

The same way we auto-prefix packages with babel-plugin-, we do the same for packages in scopes.

I suppose one option we could consider would be to loosen those requirements when a scope is in use, and only append babel-preset- when that name is not present anywhere in the module name, rather than explicitly looking for it as a prefix. I don't think I'd want that for non-scoped packages though.

I'll also say that adding a / suffix is probably an accidental edge case, I don't think that's something we actually intended to allow. The / logic is meant to allow things like @scope/some-package/babel or something, where the preset is a file within a scoped package, but it looks like it never verifies that there is at least one character after the /.

[artola]

@xtuc version: 7.0.0-beta.51 with "babel-loader": "^8.0.0-beta.4",
@loganfsmyth Thanks for the info. I do believe that we should try first node-resolution and if fails the several appends of nowadays (or viceversa).

[loganfsmyth]

@artola Multiple-pass resolution was an ongoing pain point for us in Babel 6 because it was a frequent source of confusion, especially when people forgot to install presets. By expecting a strict 1-1 mapping, it allows Babel to give much more useful feedback when errors happen. I don't think I'd be willing to revert that.

I'd certainly be happy to discuss alternative ways to handle how the 1-1 mapping is generated though, as I mentioned above.

[artola]

@loganfsmyth I do believe that module resolution for presets (may be others, plugins?) is not crystal clear, and with many edge cases, e.g., these cases can handle scoped packages with no specific prefix with similar result:

presets: ['@company/rdk.babel-preset-xxx/'],
presets: ['@company/rdk.babel-preset-xxx/index'],
presets: ['module:@company/rdk.babel-preset-xxx'],

I would like to just do it transparently and supported by API/documentation in a way that a change to the resolution mechanism triggers a major version.

[lukescott]

Just a thought - given the major version jump of babel 7 and the built-in packages changing to @babel/: Could the plugin and presets just take the exact package name rather than allowing the user to strip babel-plugin-. That way the user could name their package what ever they wanted.

I ran into an interesting issue where I copied my .babelrc file from one project to another and tried npm installing the package. I copied the name directly from .babelrc and, of course, the package name was not found.

This was OK when babel's own packages followed the same babel-plugin- convention. So if I had proposal-class-properties I would know to do babel-plugin-proposal-class-properties, but with @babel/proposal-class-properties it was not obvious I needed to install @babel/plugin-proposal-class-properties.