Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Option to generate a map file even for vendor-bundle #343

Closed
pfurini opened this issue Sep 27, 2016 · 7 comments
Closed

Comments

@pfurini
Copy link
Contributor

pfurini commented Sep 27, 2016

I'm submitting a feature request

  • Library Version:
    0.20.0

Please tell us about your environment:

  • Operating System:
    OSX 10.11.6

  • Node Version:
    6.4.0

  • NPM Version:
    3.10.8

  • Browser:
    all

  • Language:
    all

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 the vendor-bundle

Expected/desired behavior:

  • What is the expected behavior?
    Have a configuration option to generate the source maps for the vendor-bundle
  • What is the motivation / use case for changing the behavior?
    Sometimes you are in the following conditions:
  • There's a bug or an undocumented behavior in library code, and you need to step into the code to quickly find what's happening in the browser
  • You wrapped some common components in npm packages, and you published in a private repo. You want this common components in the 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..
@EisenbergEffect
Copy link
Contributor

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.

@pfurini
Copy link
Contributor Author

pfurini commented Sep 28, 2016

@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?

@EisenbergEffect
Copy link
Contributor

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.

@pfurini
Copy link
Contributor Author

pfurini commented Sep 28, 2016

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.

@jadrake75
Copy link

jadrake75 commented Oct 22, 2016

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.

@JeroenVinke
Copy link
Collaborator

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 #624 for further improvements

@Jenselme
Copy link
Contributor

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants