Webpack-cli: Consider splitting the CLI and transformations
What is the current behavior?
Now that webpack 4 requires the CLI, which in return has a dependency on jscodeshift, this means everyone get's a copy of babel-register and all the other plugins that it needs.
Ideally this should be split out as not everyone who uses the CLI needs to transform the code.
It also causes issues when trying to use the babel-loader 8.x with babel 7.x, as jscodeshift uses babel 6.x.
If the current behavior is a bug, please provide the steps to reproduce.
Install webpack@next and the webpack-cli. Check your node_modules.
What is the expected behavior?
Split out the code transformation from the CLI, so all users don't have to have a copy of (possibly the incorrect version of) babel with every webpack install.
node8.4.0macOSHigh Sierranpm5.6.0webpack4.0.0-beta.1webpack-cli2.0.6
ryanclark
All 10 comments
I think splitting it out into webpack-transformer would be good. That could either then be the command if used to migrate, or add a --transform flag that will check for the separate npm package.
ryanclark
on 17 Feb 2018
In for this, this issue would be in relation to the monorepo strategy
evenstensberg
on 17 Feb 2018
Make the package solid first. Worry about constructing a monorepo later. I vote 馃憤 for this (and suggest the same is needed for many of CLI's feature sets)
shellscape
on 24 Feb 2018
jscodeshift also brings in babel-preset-es2015 which is deprecated in favor of babel-preset-env, as well as nomnom, which is also deprecated. I also vote 馃憤馃徎 on this.
cvkline
on 25 Feb 2018
That's on Facebook, not us. The warning will still be there
evenstensberg
on 26 Feb 2018
I guess I didn't phrase it right鈥β營 didn't mean to imply that it was something you could fix. Sorry! I just meant to echo support for the original request that that package doesn't look to have very good deps and that might cause issues for some, hence the suggestion to split out that transformation functionality from the webpack-cli basics.
cvkline
on 27 Feb 2018
Is webpack-cli migrate even used much anymore? v1 to v2 transformation, we're on v4 now..
ryanclark
on 28 Feb 2018
evenstensberg
on 1 Mar 2018
one more reason for monorepo 馃憤 馃槈
sendilkumarn
on 2 Mar 2018
261
evenstensberg
on 28 Apr 2018
Related issues
evenstensberg
路
5Comments
heyalbert
路
3Comments
RobotnickIsrael
路
5Comments
r00nscapenab
路
4Comments
larkintuckerllc
路
5Comments
Most helpful comment
Make the package solid first. Worry about constructing a monorepo later. I vote 馃憤 for this (and suggest the same is needed for many of CLI's feature sets)