Closed pfurini closed 7 years ago
This sounds very reasonable. I think there are a couple of other issues we need to tackle first, such as generating map files for the Aurelia libs. Also, we need to think what we should do if a vendor dependency doesn't have a map file. So, this can be a bit tricky.
@EisenbergEffect You're absolutely right. As a starting point you could support a string property like mapPath
in a dependency entry, and in that case the bundler will merge the specified map file (that must be relative to the path
property or main
file) in the final vendor-bundle map.
Libraries that want native cli support should include a relevant property in their package.json
file...
What do you think?
We may need something along those lines. I'd be interested to see if there is already a standard way of handling it or if there are a set of patterns that library authors tend to follow.
There is definitely a good habit of distributing min.js.map
files that sits next the minified version of a library. The sourceRoot
entry in the map file is a relative path that points to the src
folder in the same package. This is extremely important for private packages that you publish to private npm
registries.
It is easier when you deploy a single js bundle with a single js map, I don't know how harder it is when you have a multi-file deployment. I think the kendo-ui-core
project takes the approach of generating a relevant min.js.map
file for each distribution file (but it's a long time since I last used that lib).
If we take the above as the standard approach, there is no need for an extra property like I suggested, the bundler can simply search for a source-file-name
.map next to the file itself.
Regarding the actual merge process, it's possible, at least after a quick google search: https://www.npmjs.com/package/grunt-merge-source-maps https://github.com/thlorenz/combine-source-map
The source code is pretty straightforward (I just read the combine-source-map
sources in a couple of mins), so it could be included directly in the cli codebase without relying on an external lib...
P.
Our corporate project is deploying all our common "code" as a library that is used in our applications. This has been a critical issue for us. My assumption was there was just some switch we had to flick to get it to work, but it would appear to be a deeper issue. We do have our app code source mapping, but that is only usually about 5-10% of the total app (since most is encapsulated in common library code published to our internal repos) @zhhz would be most interested.
I should mention, that our need is primarily not for the vendor-bundle but for another bundle (which is our library) but from the inclusion perspective it would be the same as vendor... ie. the code is not present directly, but the modules in node_modules do have the source maps.
I have tested this, and a sourcemap is now generated for the vendor-bundle when atleast one sourcemap has been found. Keep an eye on https://github.com/aurelia/cli/issues/624 for further improvements
I have tested this, and a sourcemap is now generated for the vendor-bundle when atleast one sourcemap has been found.
That's good if you include minified files with source maps. But if like me you rely on the build process to minify your files, you're still stuck. And I don't see any improvements on this in #624. Should this issue be re-opened?
I'm submitting a feature request
Please tell us about your environment:
Node Version: 6.4.0
NPM Version: 3.10.8
Current behavior: Now I have the option to turn on/off the generation of source maps for the
app-bundle
, but I cannot find a way to have source maps generated for thevendor-bundle
Expected/desired behavior:
vendor-bundle
vendor-bundle
as they are not strictly app code. But you'd like to be able to debug them in the browser as well, even if they have tons of unit tests..