When serving es5 ngx-socket-io gives me error

[JSmithOner]

🐞 bug report

Is this a regression?

From what I remember it didn't worked with angular 9 either

Description

.

I'm using an old IPad 2 for development and just upgraded to angular 10. I'm using ngx-socket-io but I'm trying to build the project using es5. I followed the guideline for building es5 from here

I notice that angular is using even in es5 the bundle fesm2015 of ngx-socket-io causing this unknown error.
When running ng serve it says compiling ngx-socket-io : es2015 as esm2015
I needed to use old safari in order to get the debugger working, so finding the precise error is kind of painful.
notice that basic app using ng new projectName is working on my ipad.

I use this command ng serve --aot --configuration es5 --host 192.168.XX.XX

this is my first GitHub Bug report please let me know if I'm doing wrong or at the wrong place

Thanks in advance

🔬 Minimal Reproduction

I wasn't able to reproduce it on stackBlitz but basically you only have to install ngx-socket-io import it on your new project and make ng serve with host value for safari 9
-->

🔥 Exception or Error

🌍 Your Environment

Angular Version:

Safari 9
IOS 9.3.5
Angular 10.0.3

Anything else relevant?

[petebacondarwin]

It is normal for ngcc to process the ES2015 version of the library. The ES5 version of the application is created at the end of the build by downleveling the ES2015 version of the app. So the order of things is that your TS code is compiled by Angular/TypeScript, webpack bundles this with the imported 3rd party libraries into ES2015 formatted distributable files, these ES2015 files are downleveled to ES5.

Now I believe that your index.html should be setup to use the ES5 dist files on older browsers, and ES2015 otherwise.

Can you see if ES5 versions are being built if you run ng build --aot --configuration es5?

[JSmithOner]

@petebacondarwin
First of all thanks for your reply.
I think it's E5 version I also get polyfills-es5.jsand polyfills-es5.js.map builded
I'll test them on a server see if they display properly

[JSmithOner]

@petebacondarwin I get on a latest firefox on my mac (not ipad this time) this error

Uncaught TypeError: "exports" is read-only
    js common.js:266
    js vendor.js:52465
    Webpack 20
common.js:266
    js common.js:266
    js vendor.js:52465
    Webpack 20

after few problems I've managed to make it working back as es2015 on my mac the problem seems to be with es5 only

[petebacondarwin]

I wonder if there is some additional setup that is needed... Perhaps in the browserslist?

[JSmithOner]

@petebacondarwin adding safari 9 to the browserslist doesn't really change something. I'm stuck.
I've just added a more in depth look and it is bugging here (the webpack)

vendor.js

module.exports = setup;
/* WEBPACK VAR INJECTION */}.call(this, __webpack_require__(/*! ./../../webpack/buildin/harmony-module.js */ "./node_modules/webpack/buildin/harmony-module.js")(module)))

then

common.js

module.exports = setup;

[JSmithOner]

@clydin Just compiled angular-cli with your modification an looks like it's working now. Thanks a lot. Is it possible having a more in depth explanation.
Thanks in advance

[clydin]

Angular CLI 10.0 will now down-level vendor files when targeting ES5 within the application's TypeScript configuration. Vendor files were previously only down-leveled as a side effect of using differential loading which down-leveled the entire application as a post-processing step.
In this particular case, the debug package contains ES2015 features within the code chosen by the webpack configuration (browser field in the package's package.json). As a result, prior to Angular CLI 10.0, this package would not work on older browsers except when using differential loading. With Angular CLI 10.0, the package should now be usable even without using differential loading on older browsers. However, the package's code contains ES2015 features (spread operators) that require helper functions to fully down-level. These helper functions need to be referenced (imported/required) within package's code to work. Before the fix referenced in this issue, the file was assumed to be an ES module but it is actually a commonJS file (it has no require calls but it does assign to module.exports). As it was assumed to be an ES module, the down-leveling process was adding import statements to the file and not require calls. Finally, the presence of newly added import statements was in turn causing Webpack to assume that the file was an ES module file and, as a result, processing the file differently than it should. This different processing was what was breaking the package and causing the runtime error.

[JSmithOner]

@clydin Many thanks

[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.}