Angular CLI: 1.6.1
Node: 8.9.3
OS: linux x64
Angular: 5.1.1
... animations, common, compiler, compiler-cli, core, forms
... http, platform-browser, platform-browser-dynamic
... platform-server, router
@angular/cli: 1.6.1
@angular-devkit/build-optimizer: 0.0.36
@angular-devkit/core: 0.0.22
@angular-devkit/schematics: 0.0.42
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.9.1
@schematics/angular: 0.1.11
@schematics/schematics: 0.0.11
typescript: 2.4.2
webpack: 3.10.0
ng new test-ngcd test-ngnpm run build -- -sm4. `npm run build`
```chunk {0} polyfills.f039bbc7aaddeebcb9aa.bundle.js (polyfills) 60.9 kB [initial] [rendered]
chunk {1} main.7eb03a969263f31e13db.bundle.js (main) 152 kB [initial] [rendered]
chunk {2} styles.d41d8cd98f00b204e980.bundle.css (styles) 0 bytes [initial] [rendered]
chunk {3} inline.1bcc593280127905b393.bundle.js (inline) 1.45 kB [entry] [rendered]
as you can see when it build with and without sourcemap. file that it build has different hash.
i use diff tool and it said just 1 line add when enable sourcemap it something like
//# sourceMappingURL=main.b0acc5628cb9dda9f019.bundle.js.map
after i try many time i found --build-optimizer is the cause to make this happen
when i run npm run build -- --build-optimizer=false and npm run build -- -sm --build-optimizer=false file hash will match
$ npm run build -- --build-optimizer=false
chunk {0} polyfills.f4f157cdf6f48addfc3d.bundle.js (polyfills) 61.1 kB [initial] [rendered]
chunk {1} main.610542f189dd59befccd.bundle.js (main) 4.26 kB [initial] [rendered]
chunk {2} styles.d41d8cd98f00b204e980.bundle.css (styles) 0 bytes [initial] [rendered]
chunk {3} vendor.1370c911aced8968c967.bundle.js (vendor) 223 kB [initial] [rendered]
chunk {4} inline.91b31ad6717b6e25405b.bundle.js (inline) 1.45 kB [entry] [rendered]
$ npm run build -- -sm --build-optimizer=false
chunk {0} polyfills.f4f157cdf6f48addfc3d.bundle.js, polyfills.f4f157cdf6f48addfc3d.bundle.js.map (polyfills) 61.2 kB [initial] [rendered]
chunk {1} main.610542f189dd59befccd.bundle.js, main.610542f189dd59befccd.bundle.js.map (main) 4.33 kB [initial] [rendered]
chunk {2} styles.d41d8cd98f00b204e980.bundle.css, styles.d41d8cd98f00b204e980.bundle.css.map (styles) 66 bytes [initial] [rendered]
chunk {3} vendor.1370c911aced8968c967.bundle.js, vendor.1370c911aced8968c967.bundle.js.map (vendor) 223 kB [initial] [rendered]
chunk {4} inline.91b31ad6717b6e25405b.bundle.js, inline.91b31ad6717b6e25405b.bundle.js.map (inline) 1.51 kB [entry] [rendered]
i think *.js name should not different when it build with and without sourcemap. in my situation i need to build it 2 times. first for production server and other one it need sourcemap for my sentry (my error tracking). but it not work if file name is different.
filename is not different when i use @angular/cli version 1.4.9.
I would say it behaves as expected. If content of the file changed, than hash should change as well. Even if it is only source map url.
i know but i think if it not changes in 1.4.9 it should not changes in next version tools.
but for now i found solution when i disable build optimize (--build-optimizer=false) file hash with and without sourcemap now match
Yes this sounds like a bug. Build optimizer is stripping some sourcemap comments (https://github.com/angular/devkit/blob/master/packages/angular_devkit/build_optimizer/src/build-optimizer/webpack-loader.ts#L51) and maybe it shouldn't.
@mix5003 can you try manually removing that line from ./node_modules/@angular-devkit/build-optimizer/src/build-optimizer/webpack-loader.js and see if it is fixed? If so, can you submit a PR please?
@filipesilva after i remove that line this issue still exists
@filipesilva The flag in this line that cause the problem:
https://github.com/angular/devkit/blob/5d4dee030c82eb161fd31f1526f4063b5bc43ec2/packages/angular_devkit/build_optimizer/src/helpers/transform-javascript.ts#L101
Setting suppressOutputPathCheckto false resolve the issue.
@filipesilva is this issue already taken? Maybe I can have a look at it. Is the proposed change about the suppressOutputPathCheck the way to go?
Thanks
@Jefiozie no, it's not taken. You're most welcome to have a go at it! The suppressOutputPathCheck seems to be the best bet so far.
Make sure to add a test to ensure this does not regress in the future though! Here would be a good place: https://github.com/angular/angular-cli/blob/master/packages/angular_devkit/build_angular/test/browser/source-map_spec_large.ts
Hi @filipesilva , I have made the adjustments in my local branch here. I expanded the test with a check on the problem. Can you verify that this is the correct combination for this issue?
I have found some time to have a look again at this issue (thanks @mgechev for the ping).
The reason why this issue was created at first place:
i think
*.jsname should not different when it build with and without sourcemaps. in my situation i need to build it 2 times. first for production server and other one it need sourcemap for my sentry (my error tracking). but it not work if file name is different.
Problem 1:
think
*.jsname should not different when it build with and without sourcemaps.
This case can never be true (in my opinion), when using sourcemaps the compiled file will be changed. So this is creating a new hash for the file output. (as expected?)
Problem 2:
In my situation i need to build it 2 times. first for production server and other one it need sourcemap for my sentry (my error tracking). but it not work if file name is different.
This situation is resolved in a later angular-cli version > 7.2.0 with the hidden feature. You can now use hidden sourcemaps. The output is sourcemaps without a specific reference in the file. This way you can upload it to a reporting service to use it.
I hope this clear's some problems as I believe the way angular cli is working now it the correct one. But maybe I'm missing some knowledge.
cc: @mgechev , @filipesilva
@Jefiozie I think that's a good assessment! @alan-agius4, since you implemented the source map changes, do you also think using hidden option is the preferred approach in this case?
Hi @Jefiozie and @filipesilva, yes, I do agree with the above assessment.
Yes, hidden source maps is the preferred approach and one of the main reasons why they were introduced was to cater for sourcemaps that are primary used in error reporting solutions, such as the above mentioned sentry.
And indeed, turning on/off sourcemaps unless hidden should produce a different file hash, since the file contents change to include the sourceMappingURL.
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._
Most helpful comment
Hi @Jefiozie and @filipesilva, yes, I do agree with the above assessment.
Yes,
hiddensource maps is the preferred approach and one of the main reasons why they were introduced was to cater for sourcemaps that are primary used in error reporting solutions, such as the above mentioned sentry.And indeed, turning on/off sourcemaps unless
hiddenshould produce a different file hash, since the file contents change to include thesourceMappingURL.