Guides - update to webpack 4

[TheDutchCoder]

With webpack 4 being released we should revisit the Guides and make sure the examples (still) work with the latest version.

Do we need/want to keep a ref to the v3 Guides somewhere for people that are stuck on older versions? If so, then we need to figure out a sound way of doing this.

Suggestions and help (very) welcome, as I probably can't tackle all Guides by myself because of my limit knowledge and time.

Let's do it! 🔥 💯

• [x] Getting started (PR: https://github.com/webpack/webpack.js.org/pull/1874)
• [ ] Asset Management (WIP)
• [ ] Output Management
• [ ] Development
• [ ] Hot Module Replacement
• [ ] Tree Shaking
• [ ] Production
• [ ] Code Splitting
• [ ] Lazy Loading
• [ ] Caching
• [ ] Authoring Libraries
• [ ] Shimming
• [ ] Progressive Web Application
• [ ] TypeScript
• [ ] Migrating Versions
• [ ] Environment Variables
• [ ] Build Performance
• [ ] Content Security Policies
• [ ] Development - Vagrant
• [ ] Dependency Management
• [ ] Public Path
• [ ] Integrations

[aswind7]

• [x] Code Splitting

[montogeek]

Do we need/want to keep a ref to the v3 Guides somewhere for people that are stuck on older versions? If so, then we need to figure out a sound way of doing this.

On https://github.com/webpack/webpack.js.org/issues/1854 was suggested to put them under a new URL, that would require a lot of work but it is better than adding deprecation notes (where it is possible) or redirections.

[TheDutchCoder]

@sqfbeijing Do you mean you want to tackle code splitting?

[wldcordeiro]

Which of the guides would be lowest hanging fruit? I'm glad to help where I can but this will be a learning experience of its own. 😄

[TheDutchCoder]

@wldcordeiro you can take a look at the current Guides and see which one's you would be comfortable with.

They pretty much go in chronological order (i.e. they "expand" on top of each other, so they'll progressively will get more advanced).

Something like Asset Management or Output Management are somewhat basic and easy to get into.

Let me know if you need a hand!

[Pokom]

@TheDutchCoder if @sqfbeijing isn't taking that, I could take a stab at it.

[TheDutchCoder]

@Pokom Go for it! ;)

[outoftime]

Just wanted to shout out that the caching guide might be a good one to look at early, as it includes a bunch of information that has changed utterly in Webpack 4 (SplitChunksPlugin etc.) Especially confusing as the banner in the top-left says Webpack 4.6.0.

[atrauzzi]

Out of curiosity, have any of the processes/steps for TypeScript changed? Especially as it pertains to tree shaking?

I'd like to avoid having babel in my project, but if it's an absolute requirement, I'd like to make sure I do so without creating any redundant config.

[kosarko]

Just a comment on the production guide

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 webpack.config.js, see https://github.com/webpack/webpack/issues/2537. Thus, conditionals like process.env.NODE_ENV === 'production' ? '[name].[hash].bundle.js' : '[name].bundle.js' within webpack configurations do not work as expected.

But https://github.com/webpack/webpack/issues/2537#issuecomment-369129702 is closed with:

This is now fixed in webpack 4. Setting mode: production or development also sets the proper NODE_ENV