Hey! Core maintainer here.<p>I see a lot of comments are basically saying our project is obsolete or sucks. That does not stop us from working on Grunt though.<p>We are still seeing record download numbers, even with the 2 year old releases. This is why we felt it was important to keep releasing this software and supporting developers.<p>For those who support and use Grunt - huge thank you! Pick up your free open-source copy made by volunteers on npm.
Obsolete before it hit 1.0.
While grunt/gulp was fun for a while... i am not looking back to our 800 line grunt file, complicated async configuration and the tons of dev-dependencies.<p>Webpack blew everything out of the water. 80 lines of config, hot-reloading, code-spliting, hash-filenames...
Looking forward to whats coming next.
I don't see the hype behind build tools. I still use Grunt on just about any project because I can just copy/paste the entire build process from another project and never come back to it again. Don't see much point in switching to anything else.
Lately the decline in popularity of Grunt has been more and more noticeable for me. When adding new packages there are always usage instructions for Gulp, sometimes webpack and alternatives as well but Grunt seems to be notably absent.
I'm contemplating switching to one of the more popular task runners, but that would mean having to rebuild a working flow.<p>The question also remains what happens when you have to revisit an existing site in x years. Will all the packages still be available, do I have to go back to node version x and will everything still work on Windows/Mac OS version y?
I have yet to find a use for Grunt that would not be better served with either a more modern replacement or, more commonly/simply/pleasantly, an older replacement like plain old 'make'.
I still use Grunt for small, one-off tasks that I'd like to be able to configure declaratively. For example, it's useful to wrap Webpack to make simple static deploys: <a href="https://github.com/thomasboyt/monotron/blob/master/Gruntfile.js" rel="nofollow">https://github.com/thomasboyt/monotron/blob/master/Gruntfile...</a><p>I imagine that if I was more comfortable with shell scripting I could just use that, but I do like declarative tasks a lot, and there's very little overhead to adding Grunt to a JavaScript project.
People keep saying "every grunt package makes its own way of doing things." I have not found that to be the case at all. Grunt has a lot of ways to specify groups of files, and many packages only show example usage for one of them, but they are actually largely interchangeable.<p>I'm a little incensed at the speed of it. It is very slow, for no apparent reason. But now I'm also wondering if it's not grunt's fault and actually the NPM ecosystem's fault for being way too dependency happy. I got a complaint from Windows about file name lengths being too long. Not in 20 years of using Windows have I seen this error but on corporate copy-folder-as-version-control network drives and NPM packages. So I'm concerned it might be spending most of its time just crawling my node_modules folder, because I only just now thought of this wrinkle and haven't stopped posting long enough to go do anything about it.
Well since this has seemly turned into a forum for build tool gripes, I'd like to note that no build tool is the best build tool. It simply comes down to what's maintainable for you and your team.
you don't need grunt <a href="https://medium.com/@julesbou/you-don-t-need-grunt-a48605915319" rel="nofollow">https://medium.com/@julesbou/you-don-t-need-grunt-a486059153...</a>