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've been working on a private fork of grunt-hub that adds a (pretty big) feature: the ability to run sub-Gruntfiles in dependency order (e.g. implicitly specify that project1/Gruntfile.js depends on project2/Gruntfile.js, and given that have the hub Gruntfile build project2 before project1). We've been needing this internally at my company and your codebase seemed like the most logical place to start.
It works by adding an option to hub targets called dependencyFn, a function which takes in (1) a Gruntfile path and (2) the set of Gruntfiles known by this hub target, and returns an array of Gruntfiles that the given Gruntfile depends on. The user can either provide their own implementation, or give a string referring to one of the default implementations. (Currently, we've only implemented "bower" to find relative dependencies in a bower.json and depend on any Gruntfiles in them, but it'd be easy to add any other common cases.)
Would you be open to merging this back into grunt-hub? I haven't fully tested yet to be sure, but I believe the only back-compat break is that support for specifying the level of concurrency is dropped (it uses maximum concurrency by default due to a switch from using async.queue to async.auto)--but that may be fixable if it's important. It's also a substantial rewrite of the majority of hub.js.
Let me know what you think!
The text was updated successfully, but these errors were encountered:
Hey @shama,
I've been working on a private fork of grunt-hub that adds a (pretty big) feature: the ability to run sub-Gruntfiles in dependency order (e.g. implicitly specify that
project1/Gruntfile.js
depends onproject2/Gruntfile.js
, and given that have the hub Gruntfile build project2 before project1). We've been needing this internally at my company and your codebase seemed like the most logical place to start.It works by adding an option to
hub
targets calleddependencyFn
, a function which takes in (1) a Gruntfile path and (2) the set of Gruntfiles known by this hub target, and returns an array of Gruntfiles that the given Gruntfile depends on. The user can either provide their own implementation, or give a string referring to one of the default implementations. (Currently, we've only implemented"bower"
to find relative dependencies in abower.json
and depend on any Gruntfiles in them, but it'd be easy to add any other common cases.)Would you be open to merging this back into grunt-hub? I haven't fully tested yet to be sure, but I believe the only back-compat break is that support for specifying the level of concurrency is dropped (it uses maximum concurrency by default due to a switch from using
async.queue
toasync.auto
)--but that may be fixable if it's important. It's also a substantial rewrite of the majority ofhub.js
.Let me know what you think!
The text was updated successfully, but these errors were encountered: