Recently I tried bootstrapping it with `create-react-app` and ejecting, so I can modify webpack config. `yarn start` kept linting something deep inside `node_modules`, and failing for some nefarious reason even after linting step was removed completely from everywhere I could reach. `build` command work fine, though, so go figure.
Not sure if "magic comments" will solve my problem, but it surely is nice to have simple alternative, thanks substack and everyone behind browserify! https://github.com/substack/node-browserify
the webpack book by survivejs takes a few hours to read completely, or an hour to read the important parts, and you'll be very comfortable with it.
https://leanpub.com/survivejs-webpack or https://survivejs.com/webpack/preface/
Holy shit, I thought you were kidding.
We're at a point where the bundler, one of a dozen elements required for a 'barebones' modern js application, needs a book.
I'm finding it hard to find motivation to do any kind of web based side projects these days because they inevitably begin with 'which combination of latest and greatest libraries do I need to spend an entire day wiring up before I can do hello world this time?'. Someone make this madness end.
Modern javascript tooling makes 90s C++ look pretty pleasant.
I am pretty much confident that everything worked well before you have made any modifications in the webpack config. So, the negative effects, that you are describing after, is a result of your efforts, but not anybody else.
And why did you want to eject in the first time? Most popular use-cases are already covered into create-react-app by default.
NODE_MODULES=../../node_modules
NODE_BINARIES=${NODE_MODULES}/.bin
BABEL_PRESETS=--presets [ es2017 react ]
BABEL_PLUGINS=--plugins [ transform-object-rest-spread ]
FLAGS= \
--transform [ babelify ${BABEL_PLUGINS} ${BABEL_PRESETS} ] \
--transform brfs \
--outfile ../../public/bundle.js \
entrypoint.js
build:
${NODE_BINARIES}/browserify ${FLAGS}
watch:
${NODE_BINARIES}/watchify --debug --verbose ${FLAGS}
yarn add --dev browserify watchify babelify babel-plugin-transform-object-rest-spread babel-preset-es2017 babel-preset-react brfsI ended up reading the Webpack 1 documentation for several weeks after 2 came out. I'd see the warning, go "oh, I better not use Webpack 1 then", and continue reading its docs. Cue lots and lots of head scratching.
Webpack developers: if you're going to release a new set of documentation for 3, then please, please make this clear.
[0]: For example, https://webpack.github.io/docs/code-splitting.html. "webpack v1 is deprecated. We encourage all developers to upgrade to webpack 2." There's a link, sure, but I didn't follow it because I had no reason to think I wasn't already on the Webpack 2 docs page. grumble grumble
Edit: and luckily it's easy to discern the webpack docs: v1 docs look ugly and are lacking information, v2 docs look much nicer and are more detailed ;) They did a great job so far improving the documentation.
I'm glad they are focusing on the ease-of-use. Otherwise, we really would start hiring webpack-developers.
Sometimes I wonder how it would have been if I sticked to Browserify.
For a tool with arcane concepts and config, the docs mixup was the cuckoo icing on the cake.
I'm still feeling bitter after seeing it introduced on my last project, a Rails app. Build times went from seconds to 15 minutes. After experiencing that I will make every effort to argue against it's inclusion on my current project (should anyone propose it).
We tried to replace Gulp with it at work for some relatively complex software but it was an absolute nightmare; Webpack is highly opinionated and to get it to build multiple different targets with different configurations requires jumping through a lot of hoops or worse, having to have separate Webpack configs and different build commands for each different asset target.
The last straw for us was how messy it got trying to build our LESS at the same time. Packaging all the LESS into your compiled JS, then having to extract it to put it in other files is absolutely ridiculous.
react-router has recent gone from version 3 to version 4, which is essentially a completely new and almost unrelated piece of software to V3 and requires a major rearchitecture of your application to make the transition. In effect it is one big breaking change.
> We intend to keep supporting the 3.x branch indefinitely (published separately on npm to aid in migration), although there will likely not be any future major versions based on that code. 4.0 is the future, but we won't leave you hanging if you want to stick with 2.x/3.x.
https://github.com/ReactTraining/react-router/releases/tag/v...
Previously discussed here: https://news.ycombinator.com/item?id=12511419
I don't see the benefit of switching if v3 allowed me to ssr and code split while v4 doesn't allow me to do both.
From the user pov it went from instantly displayed page with minimal js required to choosing one of those options.
What benefits could exist that supercede giving the user the best possible experience? (Genuine question).
I can't imagine huge speed gains going from one page to the next from this change and indeed changing pages in SPAs are essentially instant. So what could possibly be better that makes it worth getting rid of ssr and code splitting? Imo I won't be using react-router in future products because they are too fickle with their codebase.
Migrating from webpack 2 to 3, should involve no effort beyond running the upgrade commands in your terminal. We marked this as a Major change because of internal breaking changes that could affect some plugins. So far we’ve seen 98% of users upgrade with no breaking functionality at all
Again, I really appreciate all the work done to make this smooth, but there's still a little underlying "compatibility matters less than features" sentiment here.
Here's to hoping that we see a performance increase instead of a performance decrease as was the case with 2.0.