mention `npm run` in the shell scripts section
opened this issue · comments
For the Modern tools vs Shell scripts section, npm run deserves a mention since it gives you many of the benefits of shell scripts without all the up-front configuration that many of the other tools require. Here's the article I wrote about using npm run with the package.json scripts field: task automation with npm run.
Augmented with other narrowly focused tools on npm, you can get a lot done. Here's another example that uses catw and watchify to watch and rebuild less and javascript whenever a file changes.
The biggest benefit to this shell-oriented way of organizing things is that you don't need up-front coordination among the tool authors, so it's much easier to integrate pieces that have already been written that can read and write to stdin and stdout rather than having to write a grunt-* or gulp-* plugin to wrap the functionality manually. You're much more free to recombine the pieces in novel ways and to add components piecemeal. The downside is that there is a learning curve if you don't already know bash and it can take time to discover which tools you really like and fit your mental model and standard approaches well. This is also true of integrated solutions but there is more prescription about which tools are the "best" which I personally dislike because I so often disagree with those prescriptions.
I think "modern tools vs shell scripts" is perhaps not the right way to phrase the dialectic here. It's more about vertically-integrated tools versus more horizontally-oriented tools, or top-down vs bottom-up or centralized vs decentralized or integrated tooling vs unix. It's the same thing as [chaotic vs lawful alignment](http://annex.wikia.com/wiki/Alignment_(Dungeons_%26_Dragons%29).
👍
I think "modern tools vs shell scripts" is perhaps not the right way to phrase the dialectic here.
I fully agree. While the motive behind this title is clearly the organically grown, unmaintainable 5k shell script that most of us have either seen or written at some point, it should be made clear that there are indeed benefits of piecing together your processing pipeline on the OS level (ie. STDIN/STDOUT) as opposed to the node level and shell scripts aren't inherently bad.
👍
It's worth mentioning npm run as that is sufficient for most modules, where as "full blown modern tools" might be more useful for large applications, where scope is much more complex.
👍 definitely, I use it a lot, and works great for simple things.
Sounds great!
Does "mention" mean a paragraph, or a short chapter? Sounds to me a short chapter is better since you have so many examples & have a richer contrast vs other concepts.
The biggest benefit to this shell-oriented way of organizing things is that you don't need up-front coordination among the tool authors, so it's much easier to integrate pieces that have already been written that can read and write to stdin and stdout rather than having to write a grunt-* or gulp-* plugin to wrap the functionality manually. You're much more free to recombine the pieces in novel ways and to add components piecemeal. The downside is that there is a learning curve if you don't already know bash and it can take time to discover which tools you really like and fit your mental model and standard approaches well.
It's more about vertically-integrated tools versus more horizontally-oriented tools, or top-down vs bottom-up or centralized vs decentralized or integrated tooling vs unix.
I personally vote for having this content explicitly called out in the book.
Does "mention" mean a paragraph, or a short chapter? Sounds to me a short chapter is better since you have so many examples & have a richer contrast vs other concepts.
A short chapter makes more since since npm run should be regarded as one of the tools to get a task done.
A strong 👍. I would love to see a chapter on npm run and the workflows it enables. @substack I enjoyed your task automation write-up and imagine others would be equally as interested in reading a complete section that fleshes his out some more.
👍
I just wanted to follow up on this section. We currently have authors working on chapters for other tools but haven't got a committed author for the npm run section just yet. Would anyone be interested in taking this one on or re-purposing some of their existing content into a 1-2 pager on the workflow for it? If we can't find an author, we'll just link to @substack's article in the interim.
@addyosmani: I'd be happy to put together a 1-2 pager for npm run.
@wilmoore still interested? :)
@wilmoore still interested? :)
Sure...I'm still up for it. I can probably start working on it next week given I'm heads-down preparing for a BETA release this week.
I've made an initial crack at documenting npm run here #66.
Thanks @wilmoore!