Not a single webpack

Introducing the report log with OrelJS on setting up a convenient development environment using SystemJS. Webpack-based builds are full of flaws; the report presents an alternative approach based on SytemJS and JSPM.

Development Environment Tasks

The main problem in organizing the development environment is that production builds and builds during development have different requirements. For a production build, the list could be like this:

Compiling TypeScript, SASS
Post processing
Tree-shaking
Bundle assembly
Minification
Download to browser

However, during development only the first and last points are needed. We absolutely do not need, and, moreover, it is harmful to collect and optimize the bundle. But what we really need and important is the convenience of development.

What I mean by ease of development:

The speed at which edits are displayed in the browser. We changed the line of code in the sources - we want to quickly see how it works in the browser. Not in all environments this happens quickly.
Convenient debugging. I would like this: we opened the browser, opened the Dev Tools console, easily set a break point, compared the source codes that we see in the browser with what we edited - and all this is transparent, convenient and does not slow down.
Control over the process, intermediate stages of compilation and assembly. Suppose we are compiling TypeScript in JavaScript - and you need to check what happened on the output.
Dependency management. It consists of two things: dependency management with external libraries, so that it is convenient to make a connection with one team, and dependency management within the project.

What's wrong with webpack

Now the headliner in the development environment is Webpack. In my opinion, he is not doing well in terms of ease of development.

To see your edits in the browser, you need to build a bundle. They wrote a line of code - the webpack collects a bundle; still have the symbol - collects again. Plus another problem - it starts building when a file changes in the file system. They printed the symbol, pressed "Ctrl + S" - the bundle is going. Another character and “Ctrl + S”, it starts the assembly again. Total 2 bundles are collected at the same time.
In terms of debugging convenience, Webpack is a bundler, and all it can do is collect bundles. In order to debug something in the browser, you need to use the source map or dig into a huge piece of code. The problem with the source map is that they a) sometimes slow down b) do not exactly match TypeScript sources. If you tried to debug async / await constructs (more precisely, what they are compiled into by the TypeScript compiler) through the source map, then you understand what I mean. It is almost impossible.
Control over the process - a little more than completely absent. Webpack - a black box. Set up a config, earned webpack, collected. Everything. We cannot see what TypeScript or SASS was compiled into.
Dependency management - everything is fine here. Even better than what I offer.

Alternative development environment on SystemJS and JSPM

When I realized that this situation did not suit me, I began to look for alternatives. We use Visual Studio in development, and for it there are cool plugins.

For SaSS - WebCompiler, which compiles SASS into CSS when clicked save. We edited a line of code, pressed Ctrl + S - and one single file is instantly compiled. It can be added to the page through the style tag using gulp (this is done once, when adding / deleting files).
Natively supported work with TypeScript. There is an option to compile when saving - the same thing, it processes one single file and also instantly. True, then the studio compiles everything else (in case the files depend on each other), but we no longer have to wait, because our edits applied. Using SystemJS and JSPM, our code is loaded into the browser.

SystemJS is a library, module loader. It allows you to load modules of any kind (ES6, CommonJS, AMD, UMD, System) into the browser. Imagine that we have three modules in three files.

We import the main module, and SystemJS, analyzing the dependencies, already loads everything else in the chain. Very convenient design during development.

Paired with SystemJS is JSPM, which saves us from having to deal with SystemJS configurations. He configures everything, knows how to assemble bundles for production, and even supports Rollup out of the box.

Thus, during development, the following scheme works:

Advantages of this approach:

The browser display speed is instant. The compilation time of one file tends to zero. No bundles during development.
Convenient debugging, because all files are downloaded to the browser one at a time. We opened the source code, we understand it, and we can clearly match the code that we wrote in the IDE. If we use the source map, we can debug the TypeScript code in the browser, if we do not like the source maps, we can debug it directly in the most compiled JavaScript. This is much more convenient, because TypeScript usually generates simple and clear JavaScript. It is easy to understand, and it is very similar to the original.
Control over the process is complete. The result of any intermediate assembly step is always available for study.
Dependency management is entirely the responsibility of JSPM.

For Angular, this approach is also applicable, except that there it is somewhat more complicated. I talked about a possible working configuration option in this article .

When assembling a production scheme, it is something like this: