Closed SayakMukhopadhyay closed 5 years ago
Why not use hidden-source-map
as the devtool
option and then filter the source map out from your upload to your cdn?
Why not use
hidden-source-map
as thedevtool
option and then filter the source map out from your upload to your cdn?
Well, for one, it means more maneuvering around webpack, CI/CD and whatever other tooling there is. All of this can avoided by giving an option to delete the sourcemaps. Of course one can(should?) use this option along with hidden-source-map
so that the source files are not commented with the sourcemap filename.
In short, this feature adds to the flexibility of this plugin without taking away anything nor modifying existing API.
@SayakMukhopadhyay thanks for your contribution. We're going to close this (and #2) as we think deleting things off of the file system is beyond the scope of this module's responsibilities (since it did not generate them).
I'm interested in what you mean by:
it means more maneuvering around webpack
and wondered if you revealed a bit more about your build process, we can help solve this problem in the correct place?
My use case is with Angular and its CLI (which abstracts webpack). By traditional practice, I did not use to generate sourcemaps at all for production. But for using Bugsnag, I needed to generate sourcemaps. This meant I had to enable sourcemap in the CLI and work around Angular CLI (somewhat) to include this plugin. Now, by default, the sourcemaps are generated in the dist
folder along with the static assets. Thus I can't serve the dist
folder blindly and I would need to either
.map
filesN.B. One other option could to be make the sourcemaps generate in another folder altogether but I don't know if the plugin can handle that.
This PR closes #2 . I have added an option
deleteSourceMaps
which by default isfalse
. On passingtrue
to this option, the plugin will delete all sourcemaps.N.B.