SystemJS to Webpack – Before You Begin
http://angularfirst.com/systemjs-to-webpack-before-you-begin/
This is a primer discussing why to move from SystemJS to webpack in your Angular project. The post also describes some of the hurdles you may run into with this effort.
While it doesn't go into specific webpack configuration, this article aims to provide an overview for someone who has heard of webpack but doesn't quite understand why or how to get started. Specific details configuring webpack with ASP.NET Core are coming in future posts.
SystemJS – Starting Point
There are several posts on this blog with examples using SystemJS to mimic Node.js module resolution in the browser. While TypeScript understands how to resolve types by npm package name during development, SystemJS fills this need in the browser by mapping package names to specific script files within the npm packages. This is an effective and minimal way to setup an Angular 2 application to load its dependencies from npm and get going quickly.
After starting with SystemJS, applications (even small ones) quickly grow to contain hundreds of ES2015 modules that are then downloaded by the browser to execute the application. This is probably not a problem during development when the browser and the server are on the same machine.
At some point, however, you may want to host your application for others to see. The performance hit of loading this many modules becomes noticeable. This situation leads to creating some type of build combining these hundreds of requests into only a handful.
Whereas SystemJS manipulates the browser to understand node module resolution, webpack (and similar build tools) manipulate the code to accommodate the browser's needs. Whether SystemJS or webpack, you continue to code the way that makes you the most productive with as many ES2015 modules in as many files as make you happy. Unlike SystemJS, webpack provides the browser with a streamlined payload to load the application as efficiently as possible.
Destination Webpack
Webpack at its core is a JavaScript module bundler meaning it takes JavaScript modules from separate files and combines them into one file. Webpack can be extended, though, by using loaders which allow you to bundle other types of files. So, while webpack doesn't understand TypeScript natively, it processes .ts
files by using a loader.
Webpack has another extensibility mechanism called plugins. Where loaders handle specific file types, plugins process the contents of the loaded files. Plugins, for example, are responsible for minifying code where variable names are shortened and whitespace is removed.
One aspect of webpack that is different from a tool such as grunt or gulp is that it is more declarative meaning you configure an object literal and that object defines what should happen when you run the webpack command. The declarative nature of webpack ideally requires less configuration code and should lead you into a build that is more optimized than if you had to wire the pieces up yourself.
There are two other npm packages that carry the webpack name but are not the bundler, itself. These packages work with the bundler to improve the development experience. They are webpack-dev-server
and webpack-dev-middleware
.
The webpack-dev-server
npm package is a lightweight development server based on Node.js and Express. It has all the basic development server features and includes hot module replacement. Hot module replacement (HMR) is a process where the development server uses a WebSocket connection to replace the code of a given module in the browser when it has changed in the development environment. This does not require a full page refresh to reflect the updates making it seamless to view your changes in the browser during development.
The webpack-dev-middleware
npm package is a little more esoteric. It runs as an in-memory store containing the build output as opposed to writing the output to disk. This can decrease the time between when you modify a file and when you can see the changes running in the browser.
Configuration Troubles
Currently in early 2017, webpack is moving from version 1 to version 2. This can lead to incompatibilities in the webpack tool chain. When configuring a webpack build yourself, expect to find out-of-date examples and see errors processing your build.
Not all loaders and plugins support both webpack 1 or webpack 2 and you may find yourself trying different versions of these npm packages with different versions of webpack. Throw in the fact that TypeScript is adding significant new features through all of this and it's a recipe for configuration troubles.
This isn't meant to scare you off, just be prepared. Expect to search through the GitHub issues of some of these frameworks looking for answers or expect to post issues yourself. It's not always clear which combination of settings are correct but the webpack community is by-and-large responsive and committed to this tooling.
This is an example of an issue you may find. While the TypeScript compiler allows comments in the tsconfig.json
file as of version 1.8, some of the TypeScript webpack loaders will blow up if there are comments in this file. There is no helpful error message, it just throws an error that a property is not defined on a null reference.
It's likely these issues are resolved over time, but you should understand what you are up against.
Replacing SystemJS
Now that you know about webpack's advantages and potential pitfalls, what are the general steps required to replace SystemJS? This is a summary:
- Move polyfill scripts from index.html into the webpack bundle
- Compile and bundle the TypeScript files
- Move any external component HTML templates and stylesheets inline
- Add a reference to index.html for the new bundled resource
Move polyfill scripts from index.html into the webpack bundle
Many Angular tutorials instruct you to put polyfill dependencies directly in the index.html
(or alternatively named default HTML) file. This approach works and will continue to work with webpack but you should consider moving these dependencies into the webpack configuration.
First, including these dependencies into a bundled request improves performance. Second, having all your script dependencies in one place decreases the time to find a given dependency – thus increasing maintainability. Third, webpack resolves dependencies through node module resolution meaning you add the package name to the configuration and you're done. Using SystemJS, you often must identify the correct script to load from within the npm package.
Compile and bundle the TypeScript files
While you could continue to compile TypeScript with the TypeScript compiler, the idea is to move everything into webpack. There are several loaders that handle TypeScript files and are generally straightforward to configure. A popular TypeScript loader in the Angular community now appears to be awesome-typescript-loader.
Move external component HTML templates and stylesheets inline
This one is Angular-specific. When you have components with external templates and/or stylesheets, Angular loads these files as separate requests. By using a loader like the angular2-template-loader, the build now can combine the contents of the external templates and stylesheets into the component script itself.
Note: Understand that by moving the templates and stylesheets inline, setting the
@Component
directive'smoduleId
property is unnecessary. Leaving themoduleId
property set in the component can lead to issues. While the available tooling should most likely handle this, you may find you must account for this yourself by removing the settings manually or creating automation.
Add a reference to index.html for the new bundled resource
Finally, once you define the file(s) that webpack outputs, you must reference the new bundled file(s) in your main HTML file. As you may have guessed, there are even webpack plugins to handle this as well based off the webpack configuration (see html-webpack-plugin).
Additional Configuration
While the previous sections listed the necessary pieces of a basic webpack build. You have so many more options available to you to optimize your code. Some build steps to consider are: Ahead-of-time (AOT) compilation, using the wwwroot folder in ASP.NET Core, tree-shaking, running tests, and using the webpack development server with hot module replacement.
Tackling the Beast
So, you still want to get going with webpack? Where do you begin? There are many projects on Github and other sites that provide insight into how this tool works. It appears to still be hit or miss as far as quality. Looking at it from an ASP.NET developer's perspective, the guidance options are fewer. With that said, here are some links to get started:
- Webpack 1 – Getting Started
- Webpack 2 – Getting Started
- Angular Webpack Documentation
- ASP.NET Core JavaScript Services
None of these resources paint the full picture but they provide a good overview. In addition to these general resources, visit the documentation for the individual loaders and plugins to get details regarding compatibility with other packages.
You should consider creating your own webpack build from scratch. There are advantages to doing it this way. If you like knowing how these tools work, this is a rewarding way to learn, albeit a time-intensive one.
Focus on one piece of the build at a time. It's easier to identify which pieces of the build are failing and you can more easily investigate or replace that specific loader or plugin to compare results. Once you stabilize one part, move on to the next until you have the build that you want.
Start with the pieces outlined in the Replacing SystemJS section and continue from there.
More on the Way
You've learned why you should consider moving to webpack and the general approach to creating a webpack-based build. Again, this is just a primer. The plan is to ultimately provide you with a webpack configuration that works well with Angular and with ASP.NET Core. You will see more posts about webpack here soon.
For now, what are your favorite webpack resources? Did you build a template that others may find useful? Please share in the comments.
SystemJS to Webpack – Before You Begin的更多相关文章
- Webpack vs Browersify vs SystemJs for SPAs
https://engineering.velocityapp.com/webpack-vs-browersify-vs-systemjs-for-spas-95b349a41fa0 Right no ...
- (三) Angular2项目框架搭建心得
前言: 在哪看到过angular程序员被React程序员鄙视,略显尴尬,确实Angular挺值得被调侃的,在1.*版本存在的几个性能问题,性能优化的"潜规则"贼多,以及从1.*到2 ...
- 从Angular2路由引发的前后端路由浅谈
笔者的学习进度比较慢,直到两年以前写的网站都还是以服务端为主导的,即网站的所有视图都由服务器视图模板来渲染,笔者使用的是 DotNet MVC,开发套路就是在Controller里面写Action,在 ...
- [React] 01 - Intro: javaScript library for building user interfaces
教学视频: http://www.php.cn/code/8217.html React 教程: http://www.runoob.com/react/react-tutorial.html 本篇是 ...
- 1.初步认识TypeScript
简介:typescript是C#之父主导的一门语言,本质上是向Javascript语言添加了可选的静态类型和基于面向对象的诸多特性.相当于javascript的超集,其包含es6.由于是和C#之父创造 ...
- 深入浅出 Typescript 学习笔记
TypeScript 是 JavaScript 的一个超集,支持 ECMAScript 6 标准. TypeScript 由微软开发的自由和开源的编程语言. TypeScript 设计目标是开发大型应 ...
- 微前端框架 single-spa 技术分析
在理解微前端技术原理中我们介绍了微前端的概念和核心技术原理.本篇我们结合目前业内主流的微前端实现 single-spa 来说明在生产实践中是如何实现微前端的. single-spa 的文档略显凌乱,概 ...
- [笔记]ng2的webpack配置
欢迎吐槽 前言 angular.cn教程中用的是systemjs加载器,那用webpack应该怎么配置呢?本文 demo: https://github.com/LeventZheng/angular ...
- webpack基本配置
module: { rules: [ { test: /\.css$/, use: ['style-loader','css-loader?minimize'] } ] } 一.入门 loader可以 ...
随机推荐
- [Linux]vbox 虚拟机添加新磁盘
情况是这样的,开始创建虚拟机的时候硬盘设置太小了,只有10g,我现在通过vbox的设置给这个linux(centos6.6)虚拟机添加了一块硬盘. 下面的操作就是怎么把硬盘挂载到系统中. 通过 fdi ...
- RTB--Real TimeBidding模式的互联网广告(实时竞价的广告投放)
RTB(real time bidding)实时竞价允许广告买家根据活动目标.目标人群以及费用门槛等因素对每一个广告及每次广告展示的费用进行竞价.竞价成功后获得广告展示机会,在展示位置上展示广告. 其 ...
- Dynamics CRM 2013 subgrid刷新后刷新主表单
项目中会遇到这样的需求,会根据subgrid中的数据变化去更新主表单中的某个或多个字段值,一般的做法就是写插件根据subgrid中实体数据的变化在后台更新主表数据库,但后台更新了要反映到前台就得使用刷 ...
- Spring BeanFactory getBean 源码剖析
首先看一张时序图 最开始,一切都来自这里: public static void main(String[] args) { ApplicationContext context = new Clas ...
- listview的工作原理
/** * Unsorted views that can be used by the adapter as a convert view. */ private ArrayList<View ...
- PDA智能设备解决方案打包及部署
演练:打包智能设备解决方案以便进行部署 Visual Studio 2008 本演练演示如何使用 Visual Studio 将应用程序及其资源打包到一个 CAB 文件中,以便可将其部署到最终用户的智 ...
- Java进阶(二十一)java 空字符串与null区别
java 空字符串与null区别 1.类型 null表示的是一个对象的值,而并不是一个字符串.例如声明一个对象的引用,String a = null ; ""表示的是一个空字符串, ...
- C++中const的实现细节介绍(C,C#同理)
via:http://www.jb51.net/article/45755.htm 本篇文章主要是对C++中const的实现细节进行了详细的介绍,需要的朋友可以过来参考下,希望对大家有所帮助 1.什么 ...
- #一周五# VS2015 CTP6, TFS2015 CTP1更新,老衣的开发工具汇总,2015 MVP 社区巡讲
又到周五,这一周博主我工作效率极高,每天更新博客一篇,<快速创建网站>系列已经进程大半了,希望这个系列能够对大家有所帮助.今天周五了,博主要休息一下,就给大家唠叨一下这段时间都发生了什么. ...
- How to Simulate the Price Order or Price Line Function using API QP_PREQ_PUB.PRICE_REQUEST Includes
How to Simulate the Price Order or Price Line Function using API QP_PREQ_PUB.PRICE_REQUEST Includes ...