ng serve/test/e2e differential loading and IE support

[benouat]

🐞 Bug report

- [ ] new
- [ ] build
- [x] serve
- [x] test
- [x] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

Is this a regression?

To me this sound as a regression. ng serve/test/e2e used to work out of the box for Internet Explorer on a freshly created project.

Now it simply doesn't without tweaking the configuration (as proposed here) (which I clearly do not want to embrace... see my points in description below)

Description

I would like to be able to develop and test on legacy platforms in a transparent way. But I also want to benefit from differential loading.

ng build supports differential loading both in dev and prod mode, apparently ng serve and ng test don't. (ng e2edoes not either as being build on top of ng serve)

I am fine for ng serve not doing it but I still do want to have ng test/e2e working with real differential loading. It is even mandatory for anyone that needs to test Internet Explorer support.

Workarounds proposed:

• Revert back to pre ng-cli-8 era (ie target: es5 for everyone in tsconfig.json and no differential loading).
• Maintain 2 different build paths / configuration in my package.json/angular.json

None of these workarounds suit my need.

🌍 Your Environment

Angular CLI: 8.0.1
Node: 10.9.0
OS: darwin x64
Angular: 8.0.0
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.800.1
@angular-devkit/build-angular     0.800.1
@angular-devkit/build-optimizer   0.800.1
@angular-devkit/build-webpack     0.800.1
@angular-devkit/core              8.0.1
@angular-devkit/schematics        8.0.1
@angular/cli                      8.0.1
@ngtools/webpack                  8.0.1
@schematics/angular               8.0.1
@schematics/update                0.800.1
rxjs                              6.4.0
typescript                        3.4.5
webpack                           4.30.0

Anything else relevant?

Trying to dig down all these things, I also ended up looking at the code of this commit

angular-cli/packages/angular_devkit/build_angular/src/angular-cli-files/plugins/karma-debug.html

Lines 32 to 33 in 6ec0991

	<script src="_karma_webpack_/polyfills.js" crossorigin="anonymous"></script>
	<script src="_karma_webpack_/polyfills-es5.js" crossorigin="anonymous" nomodule></script>

What's the point of doing that? Any old browser will end-up loading both of them. Line 32 shouldn't have a type="module" ?

Even more, what's the point at all to load an es5 compatible bundle where all the other one are only es2015 ?

Are my below statements right ?

• On an es2015 compatible platform, this polyfills-es5.js should not be needed.
• On an old es5 compatible platform, if polyfills.js (even runtime.js which comes before) is es2015 it would'nt fly and would crash with syntax error (which is the case)

I am really confused about this change performed in this commit... 😞

[alan-agius4]

Hi, @benouat

Let me answer some of your questions :)

On an es2015 compatible platform, this polyfills-es5.js should not be needed.

Indeed this is true, infact it won't be downloaded because of the nomodule attribute.

On an old es5 compatible platform, if polyfills.js (even runtime.js which comes before) is es2015 it would'nt fly and would crash with syntax error

The polyfills.js should always be downloaded irrespective if the browser supports es2015 or not, because in this file there are polyfills which are always required for the application to work such as zone.js.

The polyfills file JavaScript version will be the same script target of the build, ie if it's an ES5 build the polyfills content will be in ES5 Js, while for an ES2015 build it will be ES2015.

If you want to test on non es2015 browser you'd need to provide a different configuration as per my comment #14455 (comment),

I hope the above makes some more sense :)

I think it's best to keep the discussion in a single thread, being #14455. If we see that this has a big impact on the community we will re-open and propose a better alternative for this,

Thanks.

[benouat]

@alan-agius4 Thanks for your clarification ! 👍

I think it's best to keep the discussion in a single thread, being #14455.

Nonetheless, keeping a discussion thread on a closed issue seems a bit strange to me.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}