[deleted]
Getting Started with Webpack 2
51–59 of 59 posts
Re: Getting Started with Webpack 2
#52Earlier quoted context omitted.
I'm still skeptical. Webpack is one of the saner ones. Many JS libraries are still doing break-everything major version releases- Babel and Angular come to mind.
That's what a major version is supposed to signify though, isn't it? Most JS/NPM-based projects use semantic versioning, so a major version update means breaking/backwards-incompatible.
Even if it's communicated correctly, it's still a hassle.
Re: Getting Started with Webpack 2
#53Earlier quoted context omitted.
Have you used yarn? Do you know what it is? It's a fully backwards compatible client built on the npm packaging system, using npm's repository, and built in collaboration with the npm team.
Its also awesome, I switched when it was on HN a while back and its been amazing. I seldom get excited about JS tools but yarn is an exception.
Have you tried PNPM or IED?
Re: Getting Started with Webpack 2
#54Now that Webpack has tree shaking, are there still reasons to use Rollup?
Rollup's gains come mainly from the way it combines modules into a single scope, rather than wrapping them in functions and shipping a module loader with the bundle. It's not uncommon to see parse/evaluate time plummet when switching to Rollup because of this, which is often more important than the number of bytes. However Rollup currently lacks a lot of features that make Webpack a good choice for large and complex…
Could you please expand on:
> it combines modules into a single scope, rather than wrapping them in functions and shipping a module loader with the bundle
I'm really interested, I got into JS development this year and have no idea of the internals of bundlers/packagers.
Re: Getting Started with Webpack 2
#55Earlier quoted context omitted.
That's what a major version is supposed to signify though, isn't it? Most JS/NPM-based projects use semantic versioning, so a major version update means breaking/backwards-incompatible.
Even if it's communicated correctly, it's still a hassle.
Are you complaining that things get updated? You don't have to use the absolute latest versions of everything, you can still use older versions if you want.
Re: Getting Started with Webpack 2
#56Re: Getting Started with Webpack 2
#57Earlier quoted context omitted.
I can understand your concerns but we made a promise early on that we wouldnt release v2 from beta until our MVP docs milestone is complete. We are just around 90% completion ( http://github.com/webpack/webpack.js.org/milestone/1 ) After that we will release v2. Help always wanted! <3
Can you please add some documentation for sourcemap and debugging to the doc? WP 1's sourcemap doc is confusing as hell and WP 2's doc just copied that over. I imagine debugging un-transpiled code with sourcemap is one of the most common use-cases. And I'm not alone if you look at the disqus of WP's doc[0] and a blog by @bebraw[1], one of the guys running webpack.js.org. I even opened an issue[2], I hope it can make…
By all means we take PR's as well. Our MVP list is pretty set in stone and we don't want to extend our timeline. However simply by adding the issue to the new docs repo, I'll make sure the information will get prioritized for adding.
Re: Getting Started with Webpack 2
#58Earlier quoted context omitted.
Even if it's communicated correctly, it's still a hassle.
Are you complaining that things get updated? You don't have to use the absolute latest versions of everything, you can still use older versions if you want.
Caring about upgrade paths is super important to the longevity of a project. See: Python 3 vs Ruby 2 adoption.
Taking the mentality that "I can break everything and just bump the major number" will lead to a project that either 1) is no longer is used by many people or 2) is a maintenance hell because people are staying on old versions and asking for bug fixes and improvements.
Re: Getting Started with Webpack 2
#59Earlier quoted context omitted.
> Now, the JS community seems to be thinking more about stability and backwards compatibility. That's very welcome, at least from the perspective of this grumpy server-side developer. That's exactly why the blog post suggests using yarn instead of npm, isn't it?
Have you used yarn? Do you know what it is? It's a fully backwards compatible client built on the npm packaging system, using npm's repository, and built in collaboration with the npm team.
It's not quite ready for production yet. There are still some bugs with dev dependencies and private repos that need to be addressed before we can use it.