Error: Cannot find module 'webpack-cli/bin/config-yargs' with webpack-cli 4.2.0 - reactjs

When I try to run webpack-dev-server it gives the error.
Error: Cannot find module 'webpack-cli/bin/config-yargs'
I looked around and found that you had to change the script to "webpack serve" and did that but then it gives me the following:
**[webpack-cli] Invalid configuration object. Webpack has been initialized using a configuration object that does not match the API schema.
configuration.devtool should match pattern "^(inline-|hidden-|eval-)?(nosources-)?(cheap-(module-)?)?source-map$". BREAKING CHANGE since webpack 5: The devtool option is more strict. Please strictly follow the order of the keywords in the pattern.**
My system is Windows 10 Pro and the versions are the following:
webpack: 5.6.0
webpack-cli: 4.2.0
webpack-dev-server: 3.11.0
I've also tried including "inline: false" into the devServer object in webpack.config.js but to no avail.

just few step:
add script "dev": "webpack serve"
set devtool: 'eval-source-map' in webpack.config.js
then run npm run dev or npx webpack serve
webpack v5 && webpack-cli v4 should use webpack serve instead of webpack-dev-server
if you run npx webpack serve come out
configuration.devtool should match pattern "^(inline-|hidden-|eval-)?(nosources-)?(cheap-(module-)?)?source-map$". BREAKING CHANGE since webpack 5: The devtool option is more strict. Please strictly follow the order of the keywords in the pattern.**
you can set devtool: 'eval-source-map' in webpack.config.js
usually to balance speed and debugging:
in development mode we use devtool: 'eval-source-map'
in production mode we use devtool: 'cheap-module-source-map'
you can also return webpack v4 && webpack-cli v3
or try npm i webpack-dev-server#4.0.0-beta.0 -D
see https://github.com/webpack/webpack-dev-server/releases/tag/v4.0.0-beta.0
more issues you can see
https://github.com/webpack/webpack-cli/issues/1948
https://github.com/webpack/webpack-dev-server/issues/2759

Maybe someone will need to change devtool: 'cheap-module-eval-source-map' to devtool: 'eval-source-map'

Related

Invalid Option: corejs is not a valid top-level option

I built react project with webpack and babel.
It worked well.
But, today I got some error below.
ERROR in ./index.js
Module build failed (from ./node_modules/babel-loader/lib/index.js):
Error: [BABEL] /home/rpf5573/react-discovery-v2/src/admin/admin-client/index.js: Invalid Option: corejs is not a valid top-level option.
Maybe you meant to use 'targets'? (While processing: "/home/rpf5573/react-discovery-v2/src/admin/admin-client/node_modules/#babel/preset-env/lib/index.js")
at validateTopLevelOptions (/home/rpf5573/react-discovery-v2/src/admin/admin-client/node_modules/#babel/preset-env/lib/normalize-options.js:49:13)
at normalizeOptions (/home/rpf5573/react-discovery-v2/src/admin/admin-client/node_modules/#babel/preset-env/lib/normalize-options.js:160:3)
at _default (/home/rpf5573/react-discovery-v2/src/admin/admin-client/node_modules/#babel/preset-env/lib/index.js:168:37)
....
error Command failed with exit code 2.
And this is my admin-client/.babelrc
module.exports = {
compact: true,
presets: [
[
"#babel/preset-env",
{
modules: false,
targets: {
browsers: ["since 2015"]
},
useBuiltIns: "usage",
corejs: "2"
}
],
"#babel/preset-react"
],
plugins: [
"#babel/plugin-proposal-class-properties"
]
}
What did I wrong ?
What should I do ?
Maybe you had some major version change recently?
In my case, that was the cause. And the solution was:
Completely remove node-modules folder from the project
Remove package-lock.json file from the project root folder
Perform a npm i to recreate everything
As an alternative to entirely deleting node-modules as suggested by #SysDragon. I looked deeper into why the complaint was specific to corejs. And i found a great remedy here.
In summary, these were the steps taken:
Install the latest version of core-js (or atleast version-3).
Whatever you are building "might" be making use of latest JavaScript functionality. For my case, i was working with react-16.9.0 and mdbreact-4.19.0.
Note: Core-js is a Modular standard library for JavaScript. Includes polyfills for ECMAScript up to 2019: promises, symbols, collections, iterators, typed arrays and many other features.
Then, you need to update your transpiler, babel and it's "relatives".
This block snippet helped accomplish that: yarn upgrade #babel/core #babel/plugin-transform-runtime #babel/polyfill #babel/preset-env #babel/runtime babel-loader --dev.
The --dev part is just to save them as devDependencies (if using yarn) (for npm, use --save-dev), which i advocate for especially if this is team project.
In my case, the subdirectory I was working on was part of a larger Yarn workspace in the root of the repository and removing that subdirectory from the workspace and reinstalling node_modules within the subdirectory fixed the issue.
This issue is most likely caused by dependency mismatches.

webpack --optimize-minimize vs -p

I am doing server side rendering inside my react app. Inside of app I have a few pictures so i have loder for them inside webpack-config
{
test: /\.(gif|png|jpg)$/,
loader: 'file-loader?name=assets/img/[name].[hash].[ext]',
},
If I run my code this way
cross-env NODE_ENV=production webpack --optimize-minimize --config webpack.config.prod.js,
I get an error
Warning: Prop `src` did not match. Server: "assets/img/profilna.1b1788096b2a10afe508dff672e50072.jpg" Client: "/assets/img/profilna.1b1788096b2a10afe508dff672e50072.jpg"
but if I run it like this
cross-env NODE_ENV=production webpack --p --config webpack.config.prod.js,
everything is good and functions perfectly like I want.
Why is that?
As I read -p is equivalent of
webpack --optimize-minimize --define process.env.NODE_ENV="'production'"
Since I am already setting production enviroment I don't need --define
cross-env NODE_ENV=production
with this, you are setting Node process.env.NODE_ENV but is not "being passed" or used - while bundling - inside the app. Basically, you need to create global variables for the app and set NODE_ENV to what you need by webpack. And this is what...
--define process.env.NODE_ENV="'production'"
...does. It will use Webpack DefinePlugin to set global process.env.NODE_ENV to be used while bundling the app.
I know this sounds a little bit unclear, I struggled to understand it myself but hopefully, documentation will clear that out.
Technically, NODE_ENV is a system environment variable that Node.js
exposes into running scripts. It is used by convention to determine
dev-vs-prod behavior by server tools, build scripts, and client-side
libraries. Contrary to expectations, process.env.NODE_ENV is not set
to "production" within the build script
See "Specifying the environment" for an example.

Preact and Webpack for Production

Just trying to make sure I am setting up my preact js correct for production.
In my webpack setup with preact, and run npm run build I notice with Bundle Analyzer Plugin the path for the preact js file is
/node_modules/preact/dist/preact.js and not
/node_modules/preact/dist/preact.min.js
I have uglify and minify js set up as well, but just thought it was curious that the minified package is not picked up ?
Entry script within webpack
entry: { app: './src/index.js', vendor: [ 'preact', 'preact-router' ] },
Npm Run build script
"build": "cross-env NODE_ENV=production webpack --progress -p --display-modules --display-chunks"
The default main for preact is dist/preact.js - preact.min.js is there for people who want to take advantage of minification when not applying their own (people hotlinking it off a CDN, for example), and to measure real-world output size.
You're already applying UglifyJS to your bundle by running webpack with the -p flag, so you needn't worry too much about trying to use dist/preact.min.js. It could save a few bytes, but nothing major. The file you're using (dist/preact.js) is actually already run through UglifyJS by Preact, it's just not compressed but not mangled (so the variable names remain intact).

React telling me I am using minified in dev ...

So this is my task:
gulp.task('prod', function() {
browserify({entries: [
'resources/assets/js/app.js'
]})
.transform("babelify")
.transform(envify({
NODE_ENV: 'production'
}))
.bundle()
.pipe(source('all.js'))
.pipe(buffer())
.pipe(sourcemaps.init({loadMaps: true}))
.pipe(uglify())
.on('error', gutil.log)
.pipe(gulp.dest('public/js/'));
});
yet the console still sais:
all.js:30 Warning: It looks like you're using a minified copy of the development build of React. When deploying React apps to production, make sure to use the production build which skips development warnings and is faster. See [url here that stack doesn't like] for more details.
So I am confused. Whats the deal?
When running build process, set NODE_ENV like this (linux):
NODE_ENV=production gulp build
Or (Windows)
SET NODE_ENV=production
gulp build
If you added build script to your package.json - you can run npm:
npm run --production build
Or you can try to modify your scrips:
...
.transform(envify({
'process.env.NODE_ENV': 'production'
}))
...
But this depends on what version of envify you are using
You should use minified react version for production bundles. Minifying by yourself react code is not a solution, because there are many conditions like: process.env.NODE_ENV !== 'production' in it.
You can take a look here:
We provide two versions of React: an uncompressed version for development and a minified version for production. The development version includes extra warnings about common mistakes, whereas the production version includes extra performance optimizations and strips all error messages.
So you should use react.min.js from /node_modules/react/dist instead of /node_modules/react/lib/React for production bundles.

"development mode" with jsmp bundle-sfx

Is there any way to get jspm bundle-sfx to build without setting NODE_ENV to production? I'd like to set it to development for better error messages (specifically with React, which is defaulting to some 'minimized' production mode).
Have tried this with no results:
NODE_ENV=dev `npm bin`/jspm bundle-sfx [...]
jspm 0.17 will do this by default with the jspm build command (which replaces jspm build-sfx in 0.16) automatically treating it as a production build. jspm build --dev is then the way to do development-specific builds. I'd suggest trying the upgrade path if you can - the Beta release is quite stable at this point. See http://jspm.io/0.17-beta-guide/index.html for more info.

Resources