P5.js: Removing Grunt ?

[vipulrawat]

I think that p5.js is planning a big overhaul. Why not removing Grunt task runner from all the place?
__Grunt is good but its hard to manage, update and even build process takes extra time. For me, its an added layer of bloatware with lots of files and configuration which are not updated, also it relies heavily on plugins that are not maintained now in 2018.__
Is there any way that we can shift to something new and easier to maintain (webpack or npm scripts itself can be the options.)?
Recently, all the PR's are failing to build in Travis, debugging that things also headed me to check each grunt task runner and it ate a lot of time.

[Spongman]

i did a gulp port a while back which worked quite well. unfortunately, though. moving from grunt isn't going to fix the mocha issues that are breaking the travis builds at this time.

[vipulrawat]

Oh Yes, this is definitely not a solution to the Travis issue But the Grunt build process is tedious and outdated too. This porting thought just came in between debugging the Travis issue.

[vipulrawat]

Result of npm audit:
15 out of 16 vulnerabilites are of grunt plugins.
Log file is in json format.
audit.log

[dhowe]

gulp isn't much better imho

[vipulrawat]

maybe gulp isn't better. but we can migrate to a less complex and more secure architecture and remove these vulnerable dependencies.

[outofambit]

I agree we could make the build infrastructure less complex and that it would be good to move off of grunt at this point.

I would favor simply using npm scripts over grunt or gulp. For more complex tasks, we can simply use a node script and call it from npm. I think this would make the code more legible and easier to follow for devs and it would give us the opportunity to make the tooling more friendly/helpful overall. (We could add friendlier/more helpful messaging and even localize the text!)

[limzykenneth]

I used to use npm script exclusively but I find it hard to debug the more tooling that is involved. In a way you will either need some bash-fu (which have cross platform compatibility issue) or encapsulate those logic into node scripts (which sometimes makes you wonder why you are recreating the things that build tools like grunt and gulp already does out of the box), I think at a certain point the benefit of code legibility will be lost either way. It may be better to simplify the build steps themselves first, reduce the amount of plugins/tooling that we need to use etc.

[Spongman]

I think there's definitely a benefit in re-using pre-built tools wherever possible (be it grunt, gulp, webpack, whatever...). Sure, you can reinvent the wheel. But often that leads to a solution that is less easy for others to understand.

[outofambit]

It may be better to simplify the build steps themselves first, reduce the amount of plugins/tooling that we need to use etc.

@limzykenneth I 100% agree. that's a really good point!

[limzykenneth]

As a first we can look at the npm audit packages with vulnerabilities. I have marked out grunt-release-it, grunt-saucelabs as potential packages that can be removed and/or replaced. I cannot get the saucelabs test to run without extra config on my local machine and I don't know how much it is used anyway. If cross browser automatic testing is desired we can look into karma which is already in the repo now anyway, perhaps move the mocha chrome stuff over to karma as well if possible. @Spongman You'll probably know more about this than I do.

For grunt-release-it the whole repo of the package is archived so no futher updates should be expected. I am not entirely sure what it does but the source is just 20 lines of code, we can copy it over and maintain it ourselves, switching the dependencies to the upstream release-it package (but updated of course).

More trimming will probably be possible but I suggest opening seperate issues for each tooling that we want to refine. The above is just what I found skimming through some lines.

PS. Also tagging #3296 to highlight @digitalfrost's effort to address the dependencies vulnerabilities problems.

[lmccart]

It's my feeling that our grunt solution is (mostly) stable, and improving with @limzykenneth's updates (sorry, will review this soon!). Since there was just work put into improving this, I'd rather not introduce a big reworking into things right now if there are no major issues, and instead wait until there's a moment where another solution offers very clear improvements. I'm going to close this for now, and we can revisit in the future as needed.