-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Removing Grunt ? #3409
Comments
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. |
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. |
Result of |
gulp isn't much better imho |
maybe gulp isn't better. but we can migrate to a less complex and more secure architecture and remove these vulnerable dependencies. |
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!) |
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. |
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. |
@limzykenneth I 100% agree. that's a really good point! |
As a first we can look at the npm audit packages with vulnerabilities. I have marked out For 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. |
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. |
Vite? |
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.
The text was updated successfully, but these errors were encountered: