Here is a repo showing RxJs sizes with webpack 3 and 4: https://github.com/filipesilva/webpack-rxjs-operators.

Only the used operators are retained with Webpack 4.

Webpack side-effects flag comparison on RxJs operators

This repo compares how using "sideEffects": false reduces bundle size for RxJs operators.

It includes a lazy chunk to add indirection to module loading. This prevents Webpack 3 with UglifyJS from dropping the unused RxJs imports but Webpack 4 side effect detection can still remove used code.

cd webpack-3
npm i
npm start 
# source-map-explorer will open on your browser, with all rxjs operators in the main bundle
cd ../webpack-4
npm i
npm start
# source-map-explorer will open on your browser, with only the used rxjs operators in the main bundle

Webpack 3 bundle sizes:

-rw-r--r-- 1 kamik 197609  159 Jan  5 16:37 0.js
-rw-r--r-- 1 kamik 197609 125K Jan  5 16:37 main.js

Webpack 4 bundle sizes:

-rw-r--r-- 1 kamik 197609 5.7K Jan  5 16:40 0.js
-rw-r--r-- 1 kamik 197609 8.7K Jan  5 16:40 main.js

License

MIT

@IgorMinar I created a similar repro with a basic Angular app (https://github.com/filipesilva/webpack-angular) and the results weren’t so good. There was no real size difference.

I think this is because Angular 5 uses flat ESM.

According to doc in https://github.com/webpack/webpack/tree/next/examples/side-effects:

The "sideEffects": false flag in big-module’s package.json indicates that the package’s modules have no side effects (on evaluation) and only expose exports. This allows tools like webpack to optimize re-exports. In the case import { a, b } from "big-module-with-flag" is rewritten to import { a } from "big-module-with-flag/a"; import { b } from "big-module-with-flag/b".

Since Angular 5 is using flat ESM, it is not possible to rewrite import { something } from '@angular/core'; to import { something } from '@angular/core/something'; because there is no @angular/core/something dir/file.

We should run some tests with a non-flat ESM build of Angular to see the impact.

@blackholegalaxy @Lakston this the the correct issue to track resolution.

The only way to truly achieve tree shaking of RxJs (in the current context) is to use Webpack 4 and have the package marked as being side effect free.

Without these two preconditions, it is only possible to treeshake RxJs operators in the main bundle, and only if the vendor bundle is disabled (as it is by default on prod builds).

I have an Angular app using v6.1.8, CLI v6.2.3 and rxjs v6.3.2. Not importing anything from the internal path and it’s still appearing inside of the bundle, in addition to that I am seeing bunch of operators that we are not using at all.

The problem is that you have -vc turned on. Vendor chunking results terrible size regressions. This is because webpack 3 generates a ton of cross-chunk module-stitching code that prevents uglify from dead-code-eliminating the unused operators. Once you turn off vendor chunking everything will work correctly.

If things go as planned webpack 4 should significantly improve this situation, but until then definitely always always turn off vendor chunking if you care about payload size. This is why -vc is disabled in cli by default.

with vendor chunking:

without vendor chunking:

@Splaktar there is no webpack 4 issue specifically for this, it’s an optimization that was baked into the v4 branch already, so if there was an issue, it should be closed now.

I’m also not aware of a particular rxjs issue for turning on the side-effect free flag so I created one: https://github.com/ReactiveX/rxjs/issues/3212

@TheLarkInn I tried with webpack@4.0.0-alpha.3 and it still seemed to happen. I will setup a bare webpack repro tomorrow so we can look at this sort of effect in more detail.

It boils down to this:

• currently unused side-effect free exports are dropped via uglify (via the PURE comment)
• uglify can only drop code that is in the same chunk+module (via ModuleConcatenationPlugin)
• when there are multiple chunks wired via webpack modules, uglify cannot drop these exports

@IgorMinar am I missing something here?

I’ll setup a repro where webpack3+uglify is used on code using imports from rxjs with code splitting. Then I’ll try to use webpack4 and mark rxjs as being side effect free by editing package.json directly.

This should let us see the exports being dropped in webpack 4.

@songawee the issue is really in webpack v3 and the whole bundling stack outside of the cli, so it’s expected that you can reproduce it without the cli.

@filipesilva keep in mind that I don’t expect that webpack v4 will just make things work out of the box. we’ll need to flag the rxjs package as side-effect-free and possibly do even some repackaging of that npm package. all of that is planned for rxjs v6

@Splaktar the current workaround is to use module id rxjs/operators/<operator-name> instead of rxjs/operators to import operators. You definitely want lettable operators even with this flaw because the original operators that you had to bring in via /add/operator/<operator-name> always end up in the main bundle (critical path) even if they are used only in lazy-loaded code, and more importantly are headache due to far-away effects that can make your code work without /add/operator/foo import if you rely on an operator that was brought in by another part of your code or a 3rd party library (if this far-away code changes and removes the operator import, your code will suddenly break and you will wonder why).

Note that some operators come from libraries. So they are still needed in the bundle even if you don’t use them directly.

ng build --target=production -sm Pre-lettable operators (60.63 KB for RxJS):

ng build --target=production -sm With lettable operators (122.39 KB for RxJS):

ng build --target=production -sm --vc=false With lettable operators (122.39 KB for RxJS):

ng build --target=production -sm --vc false With lettable operators (122.39 KB for RxJS):

ng build --target=production -sm -vc false With lettable operators (122.39 KB for RxJS):

ng build --target=production -sm -vc=false With lettable operators (122.39 KB for RxJS):

ng build --target=production -sm -vc=false -cc=false With lettable operators (122.39 KB for RxJS):

I found this issue because I was also experiencing this issue with a custom Webpack 4 + Babel 6 setup. I then tried Rollup just for fun to see if it makes any difference. Using RxJS and one/two pipeable operators resulted in a ~10 kb bundle with Rollup. Webpack on the other hand created a 120 kb bundle. But I noticed that Rollup requires the following line in .babelrc:

{
  "presets": [
    [
      "env",
      {
        "modules": false // <- this
      }
    ]
  ]
}

After adding this line in the .babelrc file of my Webpack setup as well its created bundle file shrank by ~110 kb to about the same size that Rollup produces.

Now I guess the Angular CLI uses TypeScript instead of Babel. From reading the documentation it seems to have a similar option in tsconfig.json called compilerOptions.module and a matching value of "None".

I didn’t try this (and I don’t have any Angular projects right now) but maybe this helps you finding a solution? But at least to me this also means that this is not necessarily a Webpack issue, right?

It includes a lazy chunk to add indirection to module loading. This prevents Webpack 3 with UglifyJS from dropping the unused RxJs imports but Webpack 4 side effect detection can still remove used code.

@filipesilva 125K vs 8.7K? that’s actually a bit better than what I expected. Does the app still work?

The webpack example demonstrating this feature is here: https://github.com/webpack/webpack/tree/next/examples/side-effects

@TheLarkInn I haven’t tried v4 yet, but I did try and create a minimal webpack repo - https://github.com/songawee/webpack-example. The results are a bit different from what I expected, but the bundle size does grow when not using deep imports. Let me know if you need anything updated in the repo to make it a better example.

If we did want to test v4, would we have to specify RxJS to be side-effect: false?

I’m not sure if this bug is specific to the CLI, but I’ve reproduced the issue of increasing bundle size with RxJS without using the CLI - https://github.com/songawee/angular-example.

Perhaps there’s something more at play here? 🤔

@Splaktar I remember facing this problem some time ago when importing from rxjs/operators, so I switched to using rxjs/operators/<name> imports everywhere and haven’t had problem with RxJS bundle size ever since. It’s not a big deal, since imports are added by IDE automatically and I never have to write them manually anyway.

Maybe one option for you is to advice using deep imports (at least as a temporary solution). I’ve updated your reproduction from https://github.com/angular/angular-cli/issues/9069#issuecomment-354976634 to use this approach and RxJS bundle size is back to normal.