未加星标

The Fine Art of the Webpack 2 Config

字体大小 | |
[前端(javascript) 所属分类 前端(javascript) | 发布者 店小二04 | 时间 2017 | 作者 红领巾 ] 0人收藏点击收藏

Like this article ? Check out blog.flennik.com for more content like this!

In the constantly mutating world of webdev, skepticism and conservatism will protect you from fads, platform-jumping syndrome, endless refactoring and getting stuck on abandoned, unsupported tools. The Next Big Thing invokes zombie developers mindlessly banging their rotting fists onto their late model MacBook Pros, hopelessly migrating from framework1 to framework2 to this to that. No evaluation about whether it is necessary. No respect for the power of their existing tools or the pain of rebuilding everything from scratch every six months in a silly empty pursuit of coolness.

We have love for our existing solutions. We like Gulp. We understand it. It's helped us out. We invested a lot of time into it, we put it on our resumes. We know it does some things better than any alternative, for many years to come.

Of course, eventually and with great pain, sometimes we are forced to admit that the hype is well-founded. That perhaps this shiny new technology truly does change things.

Here is a timeline of my relationship with Webpack:

Day 1-50: Completely ignorant, except for the name: "Sounds stupid, I don't like it." Day 50-100: More positive buzz around the community: "Wow, people won't shut up about this... Everybody must be stupid." Day 101: I guess I'll at least take a look: "Isn't this more complicated, what do you get for all this config?" Day 102: My God, this is so much simpler than Gulp. Day 103: I love Webpack!

Webpack's genius is that it does two jobs at once. First, it bundles. You write import there in your js, and well, now you need a bundler. And it does css too, great. You cut down on HTTP requests. Your files come together nicely, and that's that.

But oh baby, this is just the start.

The secret weapon of Webpack, the piece that makes it revelation, is it makes babel, typescript, sass, less, jade and every other compiled file type as easy to use as vanilla js. You are already using Webpack to bundle your JS, but now you get so much more for free. Before, if you wanted to add Jade, PostCSS modules, sass, two overlapping JS frameworks, a development server and a custom build process, managing that complexity would become a full time job the day you started. Now you supply a list of loaders and plugins for your frameworks and you're done. The complexity is completely gone, neatly rolled into 80 lines of config. You might as well be using jQuery in terms of trouble, that is to say, it is very, very easy.

Want to see this in action?

Do you want to see some actual finished code so you can follow along with the article? Check out the webpack config for Au7 on Github, a mutant combination of Aurelia, Framework7 and Webpack I built that aims to deliver a unique combination of simplicity and power to webdev.

Ah, Upgrades

Before, Webpack had two major problems. First, the API was a bit odd. Their exclamation point syntax (where the first item is evaluated last, by the way) and question mark syntax are immediately confusing and hostile to newcomers.

css?modules-true!postcss-loader!sass

This is not clean code, I'm sorry.

While Webpack offered some incredible benefits, it makes you think of brilliant NASA engineers building enormous rockets, calculating trajectories, controlled burns and gravity slingshots... but putting the bathroom sixty meters from the living quarters.

The other problem, of course, was documentation, which simultaneously

managed to be too high-level and too basic to be helpful.

Both these problems have been completely smashed by Webpack 2.

The new website was clearly built with these criticisms in mind, as it carefully and methodically introduces you to the benefits, concepts, gotchas and options necessary to use the tool. It's comprehensive, straddles the line between too basic and not advanced enough, and offers a useable search function.

The API, while still mostly backwards compatible, offers much more sensible naming conventions that fit with established practices. Instead of exclamation points, you get this:

use: [ { loader: 'style-loader' }, { loader: 'css-loader' } ]

And instead of the question mark syntax, each loader accepts its own options object with key value pairs. Very clean, very powerful. It still evaluates the first item last, but I can live with that.

Combine this with downright sensible syntax changes, like changing the word loaders to rules and requiring the word loader in css-loader be fully written out for consistency, and you have a much more user-friendly interface. Webpack is rapidly becoming hard to criticize out of hand.

So how can we unlock the full power of Webpack while maintaining that simplicity that is so important?

Say Goodbye to Paragraphs-Long Commands

If you are anything like me, you have a text document somewhere listing multiple paragraph-long commands for your project that you copy and paste into the terminal to make it do things. Or even better, maybe you hold the up arrow, trying to find that one command you used last week, wading through git status , git status , git log , cd , ls , cd , ls , an endless parade of commands, where is it?!

Webpack can be like that, and even with a simple setup you can end up with something like

NODE_ENV=development webpack-dev-server -d --config webpack.dev.config.js --progress --open

While this is fairly readable, nobody wants to write this twenty times a day.

Enlightenment is here, and its name is npm scripts. Get that mess into your package.json, and now all you need to type is npm run dev , and the whole big command magically executes. And the benefits go beyond simple saved keystrokes.

By putting a name on the command, you suggest purpose. This makes it easy for others to understand. It doesn't take a rocket scientist to figure out the difference between npm run build:ios and npm run build:web . And that's good. Even if you're capable of deciphering a complex command, do you really want to? Be lazy. Lazy is good.

Second, it enforces consistency. There are officially-sanctioned publicly-accessible commands tied directly to your app. No one is going to need to ask you how to run your project or argue about which arguments to use.

Finally, it's simpler. Simple code is easy to read, easy to document, and fun to use.

In other news, I can now type npm run dev faster than my own name. I think that means I'm turning into a code.

You're Going to Want One File Okay. The default suggested method of using

本文前端(javascript)相关术语:javascript是什么意思 javascript下载 javascript权威指南 javascript基础教程 javascript 正则表达式 javascript设计模式 javascript高级程序设计 精通javascript javascript教程

主题: GulpGitCSSjQueryMacBookNASA
分页:12
转载请注明
本文标题:The Fine Art of the Webpack 2 Config
本站链接:http://www.codesec.net/view/531951.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 前端(javascript) | 评论(0) | 阅读(59)