ChunkLoadError After updating Angular 13.1

[myugo28]

Which @angular/* package(s) are the source of the bug?

compiler-cli, compiler

Is this a regression?

Yes

Description

After updating to Angular 13.1, CunkLoadError occurs when loading some modules.
It looks like the wrong js file was exported at build time.
css, looks wrong...

Below is the exported file name

src_app_authorized-routing-module_top-page-routing-module_top-page_module_ts.css, top-page-routing-module-top-page-module.js | top-page-routing-module-top-page-module

Below is the code for the applicable Routes

{
        path: '',
        loadChildren: () => import('./top-page-routing-module/top-page.module').then(m => m.TopPageModule)
      },

Please provide a link to a minimal reproduction of the bug

No response

Please provide the exception or error you saw

ERROR Error: Uncaught (in promise): ChunkLoadError: Loading chunk src_app_authorized-routing-module_top-page-routing-module_top-page_module_ts failed.
(error: http://localhost:8091/src_app_authorized-routing-module_top-page-routing-module_top-page_module_ts.js)

Please provide the environment you discovered this bug in (run ng version)

Angular CLI: 13.1.1
Node: 14.17.6
Package Manager: npm 8.3.0
OS: win32 x64

Angular: 13.1.0
... animations, cdk, common, compiler, compiler-cli, core, forms
... material, platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1301.1
@angular-devkit/build-angular   13.1.1
@angular-devkit/core            13.1.1
@angular-devkit/schematics      13.1.1
@angular/cli                    13.1.1
@schematics/angular             13.1.1
rxjs                            7.4.0
typescript                      4.4.4

Anything else?

No response

[JoostK]

Could you please share a reproduction?

[imario42]

I am facing the same issue. One lazy loaded module can not be loaded by the browser.
Unfortunately I can not provide any reproducible, because I do not know what is causing that issue. All other modules in the application seem to work fine.

What I see is a difference in which chunks "ng serve" is creating.

With cli 13.0.4 it looks like this

Chunk: src_app_modules_information_reporting_reporting_module_ts-src_app_shared_modules_forms_contro-32cd36.js
Name: -

With cli 13.1.1 it looks like this

Chunk: src_app_modules_information_reporting_reporting_module_ts-src_app_shared_modules_forms_contro-32cd36.css, reporting-reporting-module.js
Name: reporting-reporting-module

However, the browser still tries to load the chunk, which is missing then
ChunkLoadError: Loading chunk src_app_modules_information_reporting_reporting_module_ts-src_app_shared_modules_forms_contro-32cd36 failed.

[alan-agius4]

@imario42, maybe you can try to copy the problematic lazy module in a new project and see if the problem persists? If it does, clean it up as much as you can.

I suspect that this issue is being caused by #22239 or #22297 but we’ll need a reproduction to find the root cause unless someone wants to debug 😀

[imario42]

I tried to narrow it down as much as I can now. Trying to create a reproducible tomorrow.

What I found out is:

That module is using the monaco editor.
Dependencies:
monaco-editor 0.31.0
ngx-monaco-editor 12.0.0

As soon as I start to directly use its enums like
monaco.MarkerTag.Unnecessary or monaco.MarkerSeverity.Error
the bundle size increases to 7MB and the js chunk is no longer there.

If I replace the enums using their integer representation in my code the bundle size drops to 200k and it works again correctly.

[imario42]

This project can be used to reproduce that issue

https://github.com/imario42/largeChunk.git

In src/app/module-name/module-name.component.ts you will find an onInit($event) method.
With the help of the "severity" property you can toggle between generating a large or small chunk. Just comment either line 22 or 23 respectively.

With the large chunk, the navigation will fail with an error in the browser. With the small chunk it works.

[alan-agius4]

The root cause of the issue seems to be that certain libraries import css files as if they were ECMA modules Example:

import './foo.css';

But in a browser/node this is non valid syntax as this syntax is highly dependent on Webpack being used as a bundler. This also happened to work by accident in the CLI and like other Webpack specific features are not supported.

Please file an issue with the author of the library to remove the dependency on Webpack specific features as this would break if another bundler is used. Libraries should not be dependent on a specific bundler feature to work. The fact that the CLI is using Webpack is an implementation detail that can change in the future.

[nunoarruda]

@alan-agius4 thank you for your hard work!

Do you have any guidelines on what lib authors should do instead? The fullcalendar-angular authors, for example, seem to have some challenges in terms of importing CSS. See https://github.com/fullcalendar/fullcalendar-angular/blob/master/projects/fullcalendar/src/lib/fullcalendar.component.scss

Thanks!

[alan-agius4]

@nunoarruda, I am not familiar with fullcalendar and typically there are 3 ways how to consume CSS.

1. Global styles (IE: a link element)
2. Styles are injected in the DOM by JS
3. In Angular you have component styles.

The problem with fullcalendar is actually https://github.com/fullcalendar/fullcalendar/blob/ede23c4b2bf0ee0bb2cbe4694b3e899a09d14da6/packages/common/src/main.ts#L1

[iwnow]

The root cause of the issue seems to be that certain libraries import css files as if they were ECMA modules Example:

import './foo.css';

But in a browser/node this is non valid syntax as this syntax is highly dependent on Webpack being used as a bundler. This also happened to work by accident in the CLI and like other Webpack specific features are not supported.

Please file an issue with the author of the library to remove the dependency on Webpack specific features as this would break if another bundler is used. Libraries should not be dependent on a specific bundler feature to work. The fact that the CLI is using Webpack is an implementation detail that can change in the future.

but why it was working before?
always importing css files like that, and was not fall in issues

[alan-agius4]

For the time being we did a workaround to allow the above behaviour, but this potentially it will be removed in the future via #22363.

Because it worked, it doesn’t mean it is a supported. The above works because the underlying bundling tool is Webpack which allows such behaviour. The Angular CLI doesn’t support Webpack specific features.

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