Why I Left Gulp and Grunt for Npm Scripts
1–10 of 75 posts
Re: Why I Left Gulp and Grunt for Npm Scripts
#2Why don't they provide a good working example, using Browser Sync or LiveReload, Sass, etc ?
I haven't found a good build process using npm as a task manager or build tool; I haven't seen any good example on any article I've read so far; gulp was built for, and it's much clear in my opinion!
Re: Why I Left Gulp and Grunt for Npm Scripts
#3Why don't they provide a good working example, using Browser Sync or LiveReload, Sass, etc ? I haven't found a good build process using npm as a task manager or build tool; I haven't seen any good example on any article I've read so far; gulp was built for, and it's much clear in my opinion!
The article mentions two good working examples that do everything you mentioned and more:
https://github.com/coryhouse/react-slingshot https://github.com/kriasoft/react-starter-kit
Re: Why I Left Gulp and Grunt for Npm Scripts
#4Using npm instead of Grunt/Gulp/etc. has been extensively discussed by Keith Cirkel at http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool.... Would've been nice to at least acknowledge that, if not join efforts and try to address some of the inherent shortcomings (e.g. the readability of long lines - https://github.com/keithamus/npm-scripts-example/issues/30).
Re: Why I Left Gulp and Grunt for Npm Scripts
#5Most of the issues with Grunt and the like can be done away with by following good coding practices. i.e. keep your code outside the Grunt context and write unit tests for it. See the Thin Grunt Manifesto:
https://www.exratione.com/2015/08/thin-grunt-manifesto/
I'm not sure I buy fleeing to the command line as a viable alternative. You are in essence going to have to write a bash script at some point because the command will bloat beyond what can be sanely contained in a JSON property. Then you have to write tests for it. So why not just do that in Javascript, since you already have the infrastructure sitting there.
I think it is the case that most groups simply write lazy Grunt code in ways that make it hard to test. This is a chronic problem throughout the devops space; the code is frequently terrible. So don't do that. Don't drag the Grunt instance out into your code. Separate your concerns. Write testable functions and classes.
Re: Why I Left Gulp and Grunt for Npm Scripts
#6I'm moving in a similar direction for similar reasons - but by shifting functionality out of the node ecosystem altogether. I recently released devd, a small, dev-focused HTTP server with build-in livereload which has taken the place of gulp livereload and node-based dev servers for many of my projects (https://github.com/cortesi/devd).
I'm now working on the next step. It's not quite ready to be announced yet, but I'm cooking up modd, a similarly focused tool for monitoring the file system and responding to changes (https://github.com/cortesi/modd). Modd has already supplanted gulp entirely for many of my use cases, and has replaced supervisor and a bunch of other tools to boot. Many of the actions triggered by modd for front-end projects are precisely invocations of npm scripts as described in the article. A few more features (desktop notifications with Growl/notify, and script access to the list of changed files), and modd will be ready for me to ask for public feedback.
Both modd and devd are small, single-purpose tools written in Go, released as statically compiled binaries with no external dependencies. I've tried to make them tight and focused, and if I get it right, they will hopefully be a refreshing change after gulp and grunt.
Re: Why I Left Gulp and Grunt for Npm Scripts
#7Why don't they provide a good working example, using Browser Sync or LiveReload, Sass, etc ? I haven't found a good build process using npm as a task manager or build tool; I haven't seen any good example on any article I've read so far; gulp was built for, and it's much clear in my opinion!
It isn't 100% up to date anymore, but I made a web app repo [0] that gives you everything you need for a frontend app. This repo is very close to what we're using in my job for our app.
Furthermore, I wrote a related blog post [1] about this a few months back. You don't need gulp.
[0] http://github.com/cesarandreu/web-app
[1] https://github.com/cesarandreu/blog/blob/master/a_reasonable...
Re: Why I Left Gulp and Grunt for Npm Scripts
#8I wrote a related blog post [0] and provided a sample starting point [1] a few months back.
I'm amazed more people haven't heard of webpack, it solves a ton of these problems.
[0] https://github.com/cesarandreu/blog/blob/master/a_reasonable...
Re: Why I Left Gulp and Grunt for Npm Scripts
#9I'm moving in a similar direction for similar reasons - but by shifting functionality out of the node ecosystem altogether. I recently released devd, a small, dev-focused HTTP server with build-in livereload which has taken the place of gulp livereload and node-based dev servers for many of my projects ( https://github.com/cortesi/devd ). I'm now working on the next step. It's not quite ready to be announced yet, but…
Why create devd when you could have just used live-server? It automatically injects the LiveReload stub and watches the directory for changes.
I guess, if your end goal is to move everything away from the node ecosystem. To each their own.
Re: Why I Left Gulp and Grunt for Npm Scripts
#10I went the other way as well and used Python with Envoy to call every thing from the command line.
It's quick, easy to debug (arguments to commands can be dumped in debug mode, run manually etc).
Also for certain tasks Python annihilates Gulp plugins.
This is a production example (not pretty code per se) http://kopy.io/yvEGl when combined with intellij watchers this makes it very easy to rebuild on change.