getPluginsThatDontSatisfyModuleRange breaks when "node" missing from definition
siilike opened this issue · 11 comments
export function getPluginsThatDontSatisfyModuleRange(plugins, range) {
return _.pickBy(
plugins,
({ node }) => !semver.satisfies(normalizeSemver(node), range)
)
}
assumes that the plugin has a "node" field which proposal-nullish-coalescing-operator does not have. This causes the semver module to throw an error, because "undefined.0.0" is not a valid version.
+1 Experiencing this issue too. Pinning to 1.5.0 seems to work around this for now.
@siilike @Baune8D Thanks for reporting!
We have a couple of options here.
If the plugin entry does not have a node, we could assume that means the feature is not supported in any version of Node. So we could include these in getPluginsThatDontSatisfyModuleRange by default. But would that mean getModuleNeedsBabel would always return true, which would transpile all packages. We could do that for all packages, or just for packages that specify supported Node versions in package engines. The latter is probably preferable since most packages probably don't specify engines, so the former might transpile most of them, which may be slow.
Alternatively, we could just skip such plugins from transpile consideration for now since hopefully nobody would be publishing package in untranspiled form that relies on this syntax. Or we could only skip such packages when it specifies supported Node versions in package engines. But if a package doesn't specify engines, then always transpile - but since most packages probably don't specify engines, that might transpile most of them, which may be slow.
I also see we should probably consider migrating to relying on @babel/compat-data directly, and maybe include it (or @babel/preset-env) as a peer dependency so we're in sync with whichever major version the user is actually using to transpile.
We should assume that node simply does not support that feature. As far as I understand the information comes from @babel/compat-data and there the field is not defined when not supported (like in the case of proposal-nullish-coalescing-operator).
We should assume that node simply does not support that feature. As far as I understand the information comes from
@babel/compat-dataand there the field is not defined when not supported (like in the case of proposal-nullish-coalescing-operator).
@siilike Yes, but are you good with having it skip considering transpiling packages for these features that are in no version of Node? I hope you wouldn't want it to transpile them. The whole point of this utility is to be able to avoid transpiling all node_modules. But if no version of Node supports these features, then all packages would need to be transpiled.
Module not found: Error: Can't resolve '@babel/compat-data/plugins' in '/webpack-babel-env-deps/src'
Works fine after adding it to devDependencies.
Also, it would be great if the distribution wasn't be minified: we'd have meaningful stack traces and be easy to quickly try things out without bothering with cloning and building.
@siilike I assume that is because I've added @babel/compat-data in peerDependencies - maybe you didn't do a fresh install? Do you think I should restore it in dependencies? I would hope when someone installs @babel/* toolchain they would get @babel/compat-data in there somewhere, but maybe it wouldn't be elevated to node_modules/@babel/compat-data but under node_modules/@babel/*/node_modules/@babel/compat-data.
Seems to be working fine.