You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
sourceMap prefix, e.g. sourceMapSourceRoot, sourceMapFile.
Pros: Pretty self explanatory, simple to implement.
Cons: Fairly verbose.
sm prefix, e.g. smSourceRoot, smFile.
Pros: Simple to implement, compact.
Cons: Less self-explanatory, but easily explained via documentation.
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.
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
.I think some kind of namespacing makes sense for clarity and consistency. For example, while it might not be awful to expose
sourceRoot
via anopts.sourceRoot
option, it makes little sense to exposefile
via anopts.file
option, and I think it'd be ugly to end up with something inconsistent likeopts.sourceRoot
andopts.sourceMapFile
.Here are what seem like the most sensible ideas to me:
sourceMap
prefix, e.g.sourceMapSourceRoot
,sourceMapFile
.Pros: Pretty self explanatory, simple to implement.
Cons: Fairly verbose.
sm
prefix, e.g.smSourceRoot
,smFile
.Pros: Simple to implement, compact.
Cons: Less self-explanatory, but easily explained via documentation.
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.
The text was updated successfully, but these errors were encountered: