-
Notifications
You must be signed in to change notification settings - Fork 3
Thoughts on approach #2
Comments
Let's bring discussion here... for reference: Creating a new Task Runner ExampleREADME.MDEvery task runner should have a README.MD file with the following sections:
TasksYour task runner example must implement all of the tasks below. Each task should be mapped to an Example package.json:
(((With these mappings, we can create a scripts to measure and validate each task runner example. Validation could be part of the acceptance of PRs... Metrics could include things like timings for tasks and number of dependencies. ))) todotask:clean todotask:lint todotask:stylus todotask:sass todotask:uglify If you need to write the concatenated file to the filesystem before uglifying, write it to todotask:transpile todotask:browserify todotask:webpack todotask:build todotask:dev (((other potential tasks to add
WIP NotesPotential repository structure:
template - this is the default set of files to use whne creating a new task runner example. As described in the tasks above, the files are quite arbitrary (instead of being a real project) in order to keep things even simpler. It may still be a good idea to include a fully working app in each example as well... maybe a generate-metrics.js - for each task runner example, capture a series of metrics and spit out a little report. Can be pretty quick/dirty validate-task-runner.js -- this would be a series of tests that would ensure the example meets the requirements. It can start out simply as a script that runs |
Notes: Kill Kill stylus - only one css transform task is needed. This isn't about picking which css preprocessor is best. It's about getting a general overview of which taskrunner is best suited for a tech-agnostic general purpose build system. Kill transpile. Kill webpack. Again, this is about general purpose build systems, not about specific tech implementations. We'll look at webpack vs browserify elsewhere. What's the purpose of these?
Where do we store implementations?I think it would be instructive to have a place for them so that we can automatically build a website similar to TodoMVC from this repo. Similar to:
|
The purpose of the
Sure, fair enough. The thought here was to provide simple examples for a few common preprocessors/tools that users might want to use. Today a large user base is going to be using either straight concatenation/uglify, browserify, or webpack, so showing simple examples for these may be of benefit. This is part of the difference in vision I suppose. I'm fine with eliminating them.
This was added as a direct response to a bullet found "The Challenge" section in this repo's README:
If its not considered vital it can certainly be removed.
These are supposed to represent directories of implementations committed to the repo. I'm fine wilth having a |
Additional requirements for new implementations:
|
I think a more concrete example would be good here. I still have no idea why any script would not fall into the prefixed category.
We'll cross that bridge once we make a decision for Cloverfield. For now let's keep the barrier to providing example configs as low as we can.
Yeah, I don't think we should require that. Let's keep the barrier low.
Yeah, let's do the
I'd prefer to call out global requirements in the implementation's README. We don't want to go installing stuff globally willy-nilly. Better to make those steps clear and explicit. |
Here is a snippet from a
There is some overlap in names, which could cause some confusion or force the implementation to change its names to something less intuitive. Using a prefix means less potential for intruding on the implementation... Taking a less scientific (and a more reality based) approach, npm is probably the only implementation where this would be a concern. So, we can dump the prefixes. 😄
I can get behind this. It would still be convenient to be able to install any required globals via script, especially if we want to eventually automate the gathering of metrics/timings. What if it was a script that had to be manually run? Maybe |
Couldn't that be rewritten as:
And what does this have to do with prefixing with todotasks? If we automate verification, we'll just loop over an array of stuff that are todo tasks and only call those tasks, e.g.:
Right? It doesn't matter if there are extra tasks. We'll just ignore them. ;) |
Re: prefix So we have some good ideas with good editorializing here... We should probably reconcile this with the original text and commit it to this repo. I'm happy to give it a shot tonight. Would this make sense to commit as CONTRIBUTING.md? |
Yeah, if you want to add more detail about contributing that would be great. For now I've updated some getting started instructions in #3. |
Did you want to take a closer look at updating the docs? I think we've got the important functionality, required tasks, etc... merged into the |
Take a look at this PR: #8 Does that look like a good implementation for CSS? I changed it so that the tests run last, because some browser tests may rely on CSS to pass. |
yeah looks good to me :) |
Thanks! =) |
Thanks @ericelliott for spinning up this repo.
Ever since I read the issue on cloverfield regarding task runners I've been thinking about how this could be done. I created a gist that covers these thoughts here:
https://gist.github.com/Flet/ce3d94c2216e88d2fcc7
I understand that some of the ideas deviate a bit from your initial concept. Does any of this match your vision for this repository?
The text was updated successfully, but these errors were encountered: