Closed jsoverson closed 11 years ago
I don’t see how this improves compatibility. Could you explain with some example?
I'm also confused how this would improve future compatibility? I'm not totally opposed to this pattern, but I don't see how chaining and putting values in parens is an improvement (except visual preference for some) over defining properties.
Also, the main goal of node-task is to define a sensible and stable API that all task runners can utilize. While this repo currently includes a task builder, anyone could write their own using whatever definition syntax makes them happy. As long as the resulting object presents a compatible API, it will work.
+100, just don’t break stable and well-defined APIs, do big switch to alternative API in the future. It is always a pain.
If the configuration is sufficiently flexible enough, then it's not much of an issue and another task builder can handle this configuration.
If the API is the goal, should the definition have its own repository so discussion is centralized around the right topic and not confused with implementing code of builders and/or consumers?
It probably should, yes. It's co-mingled right now because I needed to work with an actual implementation when I was building this to see how things worked.
Taking a cue from this conversation, have you considered a builder pattern to better organize task definition? Configuration patterns like this are sensitive to change (as I'm sure you've seen with grunt).
For example:
Abstracting the api for task creation and task querying will offer (the potential) for greater future compatibilty by not having to manage backwards compat off a single, catch-all configuration method (or for each consumer if supporting the object literal syntax)