Need information: Removing as many options as possible

[phated]

I need to get an idea of how people are using all the different options and why they are using them. My goal is to understand and automatically handle those operations so this plugin doesn't need so much configuration.

Please post your option usage and why you use them below. Otherwise, your use case might disappear with the option.

List of deprecated options:

• mapSources - use sourcemap.mapSources stream.
• identityMap - use sourcemap.identityMap stream.

[phated]

mapSources has been deprecated with a separate stream API as the replacement

[phated]

identityMap has been deprecated with a separate stream API as the replacement.

[coreyfarrell]

My use case is for mapSources is to rewrite the source paths after source contents have been loaded. Once @gulp-sourcemaps/sources-content implementation is merged I won't need this.

One comment, part of me wishes that @gulp-sourcemaps/identity-map were not pulled in by this module and it were up to users to just directly use it. Mostly I'd like to see the CSS / JS parsers used by that module not pulled in automatically. Really I could see identity-map being split into two modules, one for js (acorn) and one for css. This would make it easy to replace the parsers without forcing people to switch.

I feel similarly about having the main module not directly depend on @gulp-sourcemaps/map-sources though not as strongly since that plugin doesn't pull any JS/CSS parsers

I realize that not pulling these plugins would be another breaking change but I still felt the need to mention it.

[phated]

That's very much the goal. It'll be really nice when people can just grab the modules they need and plug them together.

[coreyfarrell]

@phated How would you feel about updating the gulp-sourcemaps README so it tells people to use those modules directly instead of the mapSources and identityMap functions?

[phated]

@coreyfarrell when I've had a chance to implement the individual modules, I then import them as an export of this "grab bag" module, add an example and deprecate the option in the documentation. Do you think that's not enough? I was hoping for a gentle deprecation path before we rip out all the options in the major.

[coreyfarrell]

@phated My goal is to be able to install bare essentials, pick the pieces I need. What if we create new modules @gulp-sourcemaps/init and @gulp-sourcemaps/write? We could eventually make it so gulp-sourcemaps doesn't have any actual code, just an index.js to import / re-export the default plugins? I say eventually because I don't think the new init and write modules should ever have the deprecated options, so gulp-sourcemaps wouldn't be able to use them until it's time to actually remove those options.

[phated]

I agree but gulp 4 ships with init and write - that was the motivation behind this.

[coreyfarrell]

I'm sorry I'm not sure what you mean?

[phated]

@coreyfarrell https://github.com/gulpjs/vinyl-fs#optionssourcemaps

[coreyfarrell]

Ah I can just get the init / write functionality of gulp4 (vinyl-fs) and combine with the map-sources or whichever plugins I need. Forget everything I said about wanting to reduce the dependencies of gulp-sourcemaps itself.