Systemjs to Webpack–before you Begin

http://angularfirst.com/systemjs-to-webpack-before-you-begin/

This is a primer discussing what to move from Systemjs to Webpack in your Angular project. The post also describes some of the hurdles you are run into with this effort.

While the IT doesn ' t go into specific webpack configuration, this article aims to provide a overview for someone who has hear D of Webpack but doesn ' t quite understand what or how to get started. Specific details configuring Webpack with ASP. NET Core is coming in the future posts.

Systemjs–starting Point

There is 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-from-a-Angular 2 application to load it dependencies from npm and get going qui Ckly.

After starting with SYSTEMJS, applications (even small ones) quickly grow to contain hundreds of ES2015 modules that is T Hen downloaded by the browser to execute the application. This was probably not a problem during development when the browser and the server were on the same machine.

At some point, however, the want to host your application for others to see. The performance hits of loading this many modules becomes noticeable. This situation leads to creating some the 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) Manipulat E The code to accommodate the browser ' s needs. Whether Systemjs or Webpack, you continue to code the the-the-the-makes-the-productive with as many ES2015 modules I N as many files as make happy. Unlike SYSTEMJS, Webpack provides the browser with a streamlined payload to load the application as efficiently as Possibl E.

Destination Webpack

Webpack at its core was a JavaScript module bundler meaning it takes JavaScript modules from separate files and combines th Em into one file. Webpack can extended, though, by using loaders which allow you to bundle other types of files. So, while the 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, was responsible for minifying code where variable names was shortened and whitespace is removed.

One aspect of Webpack that's different from a tool such as grunt or gulp are that it's more declarative meaning You configure a 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 leads you to a build that's more O Ptimized than if you had to wire the pieces up yourself.

There is the other NPM packages this carry the Webpack name but is not the bundler, itself. These packages work with the bundler to improve the development experience. They is webpack-dev-server and webpack-dev-middleware .

The webpack-dev-server NPM package was a lightweight development server based on node. JS and Express. It has a basic development server features and includes hot module replacement. Hot Module Replacement (HMR) are a process where the development server uses a WebSocket connection to replace the code of A given module in the browser when it had changed in the development environment. This does isn't require a full page refresh to reflect the updates making it seamless to view your changes in the browser du Ring development.

The webpack-dev-middleware NPM package was 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 if you modify a file and when you can see the changes running in the browser.

Configuration troubles

Currently in early, Webpack are moving from version 1 to version 2. This can leads 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 your may find yourself trying different versions of the SE NPM packages with different versions of Webpack. Throw in the fact, TypeScript is adding significant new features through all of this and it's a recipe for Configurati On troubles.

This isn ' t meant to scare you off, just is prepared. Expect to search through the GitHub issues of some of these frameworks looking for answers or Expect to post issues Yourse Lf. It's not always clear which combination of settings be correct but the Webpack community is by-and-large Responsive and C Ommitted to this tooling.

This is an example of a issue you may find. While the TypeScript compiler allows comments tsconfig.json in the file as of version 1.8, some of the TypeScript Webpack loaders Would blow up if there is comments in the this file. There is no helpful the error message, it just throws an error, the A property was not defined on a null reference.

It's likely these issues is resolved over time and you should understand what's up against.

Replacing SYSTEMJS

Now so you know about Webpack's advantages and potential pitfalls, what is the general steps required to replace System Js? This is a summary:

• Move Polyfill scripts from index.html to the webpack bundle
• Compile and bundles 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 to the webpack bundle

Many Angular tutorials instruct you-put Polyfill dependencies directly in the index.html (or alternatively named default HTM L) file. This approach works and would continue to work with Webpack but you should consider moving these dependencies into the WEBP ACK 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 m Aintainability. 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 bundles the TypeScript files

While your could continue to compile TypeScript and the TypeScript compiler, the idea is to move everything into webpack. There is several loaders that handle TypeScript files and is 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 is angular-specific. When you have the 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 directive's property is @Component moduleId Unne Cessary. Leaving the property set in the moduleId component can leads to issues. While the available tooling should most likely handle this, you may find your must account for this yourself by removing th e settings manually or creating automation.

Add a reference to index.html for the new bundled resource

Finally, once you define the file (s) so webpack outputs, you must reference the new bundled file (s) in your main HTML fi Le. As may have guessed, there is even webpack plugins to handle this as well based off the Webpack configuration (see HT Ml-webpack-plugin).

Additional Configuration

While the previous sections listed the necessary pieces of a basic webpack build. You are many more options available 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, do you still want-get going with webpack? Where Do you begin? There is many projects on Github and other sites that provide insight into how the tool works. It appears to still is hit or miss as far as quality. Looking at it from an ASP. Developer ' s perspective, the guidance options is fewer. With the said, here is some links to get started:

• Webpack 1–getting Started
• Webpack 2–getting Started
• Angular Webpack Documentation
• ASP. NET Core JavaScript Services

None of the 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 Rega rding compatibility with other packages.

You should consider creating your own webpack build from scratch. There is advantages to doing it this. If you like the knowing how these tools work, this is a rewarding-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 is 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 and you want.

Start with the pieces outlined in the replacing SYSTEMJS sections and continue from there.

More on the the-the-

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 your with a webpack configuration, the works well with Angular, and with ASP. You'll see more posts on Webpack here soon.

What is your favorite webpack resources? Did you build a template which others may find useful? Share in the comments.

Systemjs to Webpack–before you Begin