-
-
Notifications
You must be signed in to change notification settings - Fork 26.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider using Webpack 2 #183
Comments
I'd love to do this, we ported |
I did it for react-boilerplate, so, it's time for create-react-app! |
hah, I was just working on this (before finding this issue). @7rulnik there's a branch here you can cop from if you find it useful: https://github.com/ChristopherBiscardi/create-react-app/tree/webpack-2 |
Sorry, I was in the middle of it already when I read this! See #189, feel free to continue the work against the |
I don't think this is as good of an idea as it might seem at first:
So essentially, webpack 1 is tried and tested and relatively easy to find documentation on. webpack 2 seems pretty stable, but it's harder to learn right now, and the path forward to tree-shaking is fraught and yields not terribly many benefits. |
Do you mean babel-plugin-lodash or lodash-webpack-plugin? |
babel-plugin-lodash, sorry. (This package inspired me to muck around with my build tooling, and I got confused.) |
Ah cool. "plugins": [
["lodash", { "id": ["async", "lodash-bound", "ramda"] }]
] |
That's super cool. To be concrete, even if you point at the React Router ES6 build in the current v3 pre-release in webpack 2, if you just do: import { Router } from 'react-router/es6'; // Or use jsnext:main. You will end up pulling in a bunch of code that you don't use, including stuff for e.g. the hash history, all the link and route helper components, &c. In practice, tree-shaking is not enough to let you change the way you write imports, unless you use babel-plugin-lodash or something similar. For a number of popular libraries, users should not rely on tree-shaking as built into the bundlers, and must find some other way to import just what they need, if they want a properly size-optimized bundle. This means that, from my perspective, tree-shaking support also always has to come with a warning that goes along the lines of "don't rely on this – you still need to do deep imports in most cases". There still is a benefit to using bundlers with native ES module support, but that benefit is restricted to getting rid of the Babel transpilation cruft. |
FWIW we have that enabled for
That's true, but the differences are tiny AND webpack warns you when you have something wrongly configured in the 1.x way. I do agree this might become a problem, though I know there's a lot of effort happening to make the webpack docs much better. (Also, |
I immediately hit breakage when I cut over my webpack config to webpack 2 earlier today. I think that's there's a pretty significant cost to impose potential breakage on inexperienced users with packages that should work, especially when the reasons for that breakage are going to be very hard for a user who doesn't know what they're doing in track down (i.e. syntax errors in |
Okay, what? The default supported ES module entry point hook in webpack 2 is actually The Rollup resolver plugin, on the other hand, doesn't know about What the heck are library developers supposed to do? Clutter up |
You can actually set that with webpack: // webpack.config.js
{
// …
resolve: {
mainFields: ['module', 'jsnext:main'] // Used to be resolve.packageMains
}
} |
I know – that's how I managed to hit breakage there earlier. I think using My issue with |
To be clear, the goal of migration is not to enable tree shaking. Right now it doesn't concern me much. The goal is to get to a place where we can quickly contribute and make fixes to Webpack without worrying about porting them to different branches. The reason I'm not too worried about semver is because we lock the version anyway, and we don't expose config to the user. But maybe I'm not seeing the risks? |
I think upgrading to Webpack 2 is great. Even getting some tree shaking is better than none. And as @gaearon said it's not really a primary goal anyway, just nice when it happens. Also, the API is nicer. As for things being confusing and having a lack of documentation for Webpack 2 when people eject, I recommend we use webpack-validator to help with that. Another thing that could be handy is webpack-config-utils which makes the config compose better (and read easier) without abstracting the Webpack API. |
My main concern is that this puts users in an incredibly difficult situation post- We all like to talk about how webpack docs aren't great. Actually, they're not that bad. I picked up webpack 1 more or less from scratch not terribly long ago by looking at some combination of the docs site, Stack Overflow questions, and the plethora of existing examples. None of these exist with webpack 2. I'd like to think I know what I'm doing now (more or less), and I had to cobble together a webpack config by going to a combination of parenthetical mentions in GitHub Wikis, an old Gist, and checking the webpack source code and open issues. I think anybody who's not already familiar with this ecosystem, when faced with a webpack 2 config after ejecting, will be, uhh, "totally screwed" is how I'd describe it – they'd not only have to figure out how to use webpack 2 from limited and spread out documentation... they'd also have to know to disregard irrelevant documentation on webpack 1. Post- |
You make good points @taion. I think that my opinion should be taken with a grain of salt because I do a lot of training and teaching about webpack and have spent hours (days/weeks?) worth of time learning and developing with it. For me, the changes from webpack 1 to webpack 2 were fairly minimal. But perhaps it would be better to wait until Webpack 2 is officially released and the docs situation is sorted out. |
This is a great point. Let’s hold this off until Webpack 2 is at least out of beta then. |
We’ll also need to do this: #613 |
Just commenting in here that webpack 2 rc has released. |
Let me know if you'd like to revive #189. |
Looks like webpack 2 officially hit final status! |
Looks like a great time to revive this. I've been working through the upgrade myself. Once it's ready, I'll submit a PR if no one else has. |
Looks like they have a PR going on over at #1291 |
Merged as of today. #1291 🎉 |
When this will be published on npm? UPD: oh, I see it is in milestone 1.0.0. For future googlers: to use it right now As always found answer in @gaearon tweet
|
When 0.10 is ready. (I’ll be looking at it this week.)
No, please don’t do this unless you really know what you’re doing. There is a reason canary releases aren’t released as stable: they are buggy and not supported. It’s fine to try them but you should expect things to break. |
Lovely to hear this is getting attention! Thanks for your efforts. |
Please help beta test the new version that includes this change! |
keep up with time! |
It’s under active development, and from what I’ve heard, most bugs have shaken out by now. I’d like to see a PR porting this project to Webpack 2 so that we may compare them, and either to switch to it, or file issues against it 😄 . I’d expect such PR to use Webpack 2’s native support for ES Modules.
If you plan to work on this, please don’t forget to comment here so we don’t have duplicate PRs.
The text was updated successfully, but these errors were encountered: