browserify / browserify/browserify
Make source map output more configurable
- Dominant language
- JavaScript
- Stars
- 14.7k
- Forks
- 1.2k
- PR merge metrics
- No merged PRs in 30d
Description
I think it makes sense to make the source map output more configurable and I want to talk about how to expose that. I know @zertosh has already [expressed support for exposing `sourceRoot`](https://github.com/substack/node-browserify/issues/681#issuecomment-103554709).
I think some kind of namespacing makes sense for clarity and consistency. For example, while it might not be awful to expose `sourceRoot` via an `opts.sourceRoot` option, it makes little sense to expose `file` via an `opts.file` option, and I think it'd be ugly to end up with something inconsistent like `opts.sourceRoot` and `opts.sourceMapFile`.
Here are what seem like the most sensible ideas to me:
1. `sourceMap` prefix, e.g. `sourceMapSourceRoot`, `sourceMapFile`.
Pros: Pretty self explanatory, simple to implement.
Cons: Fairly verbose.
2. `sm` prefix, e.g. `smSourceRoot`, `smFile`.
Pros: Simple to implement, compact.
Cons: Less self-explanatory, but easily explained via documentation.
3. `opts.sourceMap` hash, e.g. `sourceMap: {sourceRoot: '...', file: '...'}` (overwrite all defaults), and deep property merging (selectively overwrite defaults), e.g. `'sourceMap.sourceRoot': '...'`.
Pros: All source map config contained in single object instead of a bunch of separate properties, ability to overwrite all defaults just by passing an object as `opts.sourceMap`.
Cons: More complicated implementation, need to quote keys to selectively overwrite properties, fairly verbose.
See also: #1304, #1233.
I'm also interested in the idea of allowing the user to pass in a function to manipulate the source map before it's written.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.