Angular-cli: Lazy loaded styles are still hashed

[dpreindl]

Bug Report or Feature Request (mark with an x)

- [x] bug report -> please search issues before submitting
- [ ] feature request

Command (mark with an x)

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

Versions

$ node --version
v8.9.0
$ npm --version
6.0.1

Angular CLI: 6.1.1
Node: 8.9.0
OS: win32 x64
Angular: 6.1.0
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

Package Version
@angular-devkit/architect 0.7.1
@angular-devkit/build-angular 0.7.1
@angular-devkit/build-optimizer 0.7.1
@angular-devkit/build-webpack 0.7.1
@angular-devkit/core 0.7.1
@angular-devkit/schematics 0.7.1
@angular/cli 6.1.1
@ngtools/webpack 6.1.1
@schematics/angular 0.7.1
@schematics/update 0.7.1
rxjs 6.2.2
typescript 2.7.2
webpack 4.9.2

Repro steps

1. ng new lazyscss --style scss
2. Adjust angular.json to lazy load styles.sccs ( "styles": [{"input": "src/styles.scss", "lazy":true} ],)
3. ng build --prod
4. The build contains the hashed version of styles.scss

The log given by the failure

None.

Desired functionality

Based on the pull request (#11491) the hashing should be disabled for lazy loaded styles. Therefore a styles.css is expected in the dist folder (instead a styles.<hash>.css is included).
This should have been fixed with issue #11235 / pull request #11491.

Mention any other details that might be useful

It seems that the problem is caused by passing the name (e.g. "styles") in styles.ts#getStylesConfig instead of the ID (which isn't even present at the time):
https://github.com/angular/angular-cli/blob/3529096a5398526f97f0c4ace76e48bbf50431fd/packages/angular_devkit/build_angular/src/angular-cli-files/models/webpack-configs/styles.ts#L191
https://github.com/angular/angular-cli/blob/3529096a5398526f97f0c4ace76e48bbf50431fd/packages/angular_devkit/build_angular/src/angular-cli-files/models/webpack-configs/styles.ts#L200

Later, in the RemoveHashPlugin#apply the name is then compared to the actual ID:
https://github.com/angular/angular-cli/blob/3529096a5398526f97f0c4ace76e48bbf50431fd/packages/angular_devkit/build_angular/src/angular-cli-files/plugins/remove-hash-plugin.ts#L29
https://github.com/angular/angular-cli/blob/3529096a5398526f97f0c4ace76e48bbf50431fd/packages/angular_devkit/build_angular/src/angular-cli-files/plugins/remove-hash-plugin.ts#L31

Changing remove-hash-plugin.ts#L29 to use data.chunk.name instead of data.chunk.id resolved the issue in our tests.

[dashkan]

Looks like the problem is with optimization flag. When enabled the chunk id changes to a numeric value and the plugin cannot find chunkId in this.options.chunkIds.

I am going to disable optimization until there is a proper fix.

I did find the following handles both states of optimization flag:

                const chunkId = data.chunk && data.chunk.id;
                const chunkName = data.chunk && data.chunk.name;
                if ((chunkId || chunkName) && (this.options.chunkIds.includes(chunkId) || this.options.chunkIds.includes(chunkName))) {
                    // Replace hash formats with empty strings.
                    return path
                        .replace(this.options.hashFormat.chunk, '')
                        .replace(this.options.hashFormat.extract, '');
                }
                return path;

[xmlking]

I also opened similar issue
https://github.com/angular/angular-cli/issues/11772

[alan-agius4]

Thanks @dashkan and @dpreindl for taking your time into debugging this and providing your detailed analysis. I'll be looking into solving this pretty soon.

[angular-automatic-lock-bot[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._}