tivac / dullard Goto Github PK
View Code? Open in Web Editor NEWSimple, straight-forward NodeJS-powered task runner
License: MIT License
Simple, straight-forward NodeJS-powered task runner
License: MIT License
The cli
module should log errors from calling Dullard#run()
in their own line so they can take advantage of util.format
style formatting.
Currently you get a really gross stack trace.
C:\Users\kriss
λ dullard
info default build complete in 0.001 seconds
ERR! cli Build failed!
ERR! cli Error: Unknown task: default
ERR! cli at Object.assign._runTask.name [as _runTask] (C:\Users\kriss\AppData\Roaming\npm\node_modules\dullard\src\dullard.js:131:19)
ERR! cli at C:\Users\kriss\AppData\Roaming\npm\node_modules\dullard\node_modules\p-each-series\index.js:4:73
ERR! cli at C:\Users\kriss\AppData\Roaming\npm\node_modules\dullard\node_modules\p-reduce\index.js:16:10
ERR! cli at process._tickCallback (node.js:406:9)
ERR! cli at Function.Module.runMain (module.js:449:11)
ERR! cli at startup (node.js:141:18)
ERR! cli at node.js:933:3
ERR! cli [Error: Unknown task: default]
which isn't useful 🤢
If you have a steps array being run & one of the steps is the same name as a method on Array.prototype
Dullard will get confused and do something weird.
{
"steps" : [
"filter"
]
}
causes
TypeError: Array.prototype.filter called on null or undefined
at filter (native)
at async.eachSeries.self._current (C:\Users\Tivac\Documents\Programming\dullard\lib\build.js:143:26)
at iterate (C:\Users\Tivac\Documents\Programming\dullard\node_modules\async\lib\async.js:131:13)
at Object.async.eachSeries (C:\Users\Tivac\Documents\Programming\dullard\node_modules\async\lib\async.js:147:9)
at _.extend._runSteps (C:\Users\Tivac\Documents\Programming\dullard\lib\build.js:121:15)
at async.eachSeries.self._current (C:\Users\Tivac\Documents\Programming\dullard\lib\build.js:125:33)
at iterate (C:\Users\Tivac\Documents\Programming\dullard\node_modules\async\lib\async.js:131:13)
at Object.async.eachSeries (C:\Users\Tivac\Documents\Programming\dullard\node_modules\async\lib\async.js:147:9)
at _.extend._runSteps (C:\Users\Tivac\Documents\Programming\dullard\lib\build.js:121:15)
at _.extend.run (C:\Users\Tivac\Documents\Programming\dullard\lib\build.js:92:14)
at Context.<anonymous> (C:\Users\Tivac\Documents\Programming\dullard\test\build.js:338:16)
at Test.Runnable.run (C:\Users\Tivac\Documents\Programming\dullard\node_modules\mocha\lib\runnable.js:211:32)
at Runner.runTest (C:\Users\Tivac\Documents\Programming\dullard\node_modules\mocha\lib\runner.js:358:10)
at C:\Users\Tivac\Documents\Programming\dullard\node_modules\mocha\lib\runner.js:404:12
at next (C:\Users\Tivac\Documents\Programming\dullard\node_modules\mocha\lib\runner.js:284:14)
at C:\Users\Tivac\Documents\Programming\dullard\node_modules\mocha\lib\runner.js:293:7
at next (C:\Users\Tivac\Documents\Programming\dullard\node_modules\mocha\lib\runner.js:237:23)
at Object._onImmediate (C:\Users\Tivac\Documents\Programming\dullard\node_modules\mocha\lib\runner.js:261:5)
at processImmediate [as _immediateCallback] (timers.js:330:15)
It probably needs to check that the steps aren't an array before using the in
check on line lib/build.js#124
.
Sometimes we want to run dullard with a big list of gunk, without having to prepend every item with --fooga=booga
. It should be possible to support running dullard like so
dullard task -- option1 option2 option3
Need to make sure that those values are properly treated, maybe using minimist directly?
This makes sense as its trying to require it as a module.
However, a useful pattern would be putting multiple tasks in a single directory that had a common node_modules rather than writing each task as a module.
CLI args and includes
config options are both merged with addConfig()
, but the source and destination is not taken into account wrt the base .dullfile
.
https://github.com/tivac/dullard/blob/master/src/dullard.js#L291
https://github.com/tivac/dullard/blob/master/src/cli.js#L64
https://github.com/tivac/dullard/blob/master/src/dullard.js#L236
Eg:
// ./.dullfile
{
"program" : "local",
"includes" : [ "./inc/.dullfile" ]
}
// ./inc/.dullfile
{
"program" : "live"
}
Run from CLI dullard --program=dev
Results:
v1.1.0
- program === dev
v1.1.1
- program === local
module.exports = function(config) {
config.temp = path.join(shell.env.SourceRoot, "./Temp");
};
config.temp
is unset in other tasks.
Started in 4.x
, 3.0.0
is fine.
Do a pass on all the main functionality and make sure comments are sane & not stupid.
Dullard currently requires each task that it can find before actually running the selected build, which can crash the build if a task is expecting to be run in a certain environment or under specific conditions.
For instance, if a local build task requires a module that parses a file then provides an interface to interact with that file's data, the requiring task must not include that module until necessary, or change the interface to the module to allow for an initialization step.
In my opinion, it would be less surprising for developers if dullard didn't actually load its tasks completely until they are requested, since having side-effects as part of the loading of a module is a pretty common pattern. This would also have the small side effect of increased performance, especially as task libraries grow.
It's becoming a pattern that we're using arguments to override options set in the dullfile, The docs mention that the CLI takes precedence over config options, but doesn't make any mention of the fact that any arbitrary argument will override the config. I was under the impression that this only included the enumerated options. This is powerful behavior similar to -Dfoo=bar, and I think it deserves a section in the readme describing its usage.
As a bonus, would it make sense to add a bit more flexible overriding? At the moment, dullard can only override top-level config options, so would it be worthwhile to allow deeper configuration? Example:
$ dullard --foo.bar=baz
turns into:
{
foo : {
bar : "baz"
}
}
I think this would be helpful :)
aannnnd PEBKAC
Tasks that return a promise should NOT be considered a failure, they should be treated as async functions and only fail if the promise throws.
Promises should also be supported as the first argument to a done()
function (for ease of transition), and should be treated the same as if they were returned.
This will be a semver-major change because it's a breaking API change, but it'll make lots of tasks simpler to write as promises become the thing people do.
Using --loglevel=silly, --loglevel=verbose etc. doesn't appear to be working. --silly and --verbose do work though.
_.merge({ a : [ 1, 2, 3 ] }, { a : [ 11, 12 ] }); // { a : [ 11, 12, 3 ] }
Dullard currently assumes that it'll do an overwrite, not a replace. I'll need to write some custom merging logic for this so arrays do the sane thing.
The exception is pretty intense except for the first line. A better error message would be "Unable to load {module}! [Suggested steps to fix this]". This seems like it would be a common problem.
Error: Cannot find module 'U:\joshg\yui-launcher\tasks\node_modules'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at C:\Program Files\nodejs\node_modules\dullard\lib\build.js:52:32
at Array.forEach (native)
at _.extend._loadTasks (C:\Program Files\nodejs\node_modules\dullard\lib\bui
ld.js:49:15)
at C:\Program Files\nodejs\node_modules\dullard\lib\build.js:31:18
at Array.forEach (native)
at new Build (C:\Program Files\nodejs\node_modules\dullard\lib\build.js:28:2
I'm not sure what this would entail yet. I'd like to keep from adding more complexity to .dullfile
s though. Something like https://github.com/colinwren/eye may be along the right lines but the project is very immature (& abandoned?).
Instead it uses the default dullard
fallback, which isn't very useful.
info dullard complete in 366 milliseconds
info dullard complete in 204 milliseconds
info jssrvServiceLoadHashes complete in 18 milliseconds
info dullard complete in 65 milliseconds
info dullard complete in 58 milliseconds
info dullard complete in 22 milliseconds
info dullard complete in 13 milliseconds
info dullard complete in 20 milliseconds
info dullard complete in 9 milliseconds
info dullard complete in 234 milliseconds
Ideally they'd have some sort of description as well.
Also remove all the insane CLI mocking stuff I did and just run the CLI tests via execa
. It'll be fast enough.
To help automate a better changelog/commit messages across-the-board.
Is a reasonable example of a starting point.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.