Modernization of MODX's Build Environment

I think many might agree that some of the tooling for the back end’s template build is, in technology time, a relic from a bygone era. Rather than complain or keep asking very busy people to please refactor it, I’d like to take a stab at it myself.

The primary goals of a proposed change would:

  1. Enable the use of ES6 in the source javascript
  2. Change Sass implementation to Dart Sass, as Node/Lib Sass are deprecated
  3. Clean out any unnecessary tasks/dependencies

On the first goal, the strategies could be:

  • Simply replace grunt-contrib-uglify with grunt-terser and make the necessary config adjustments; or
  • Consider a move from Grunt to Webpack if modularization (now or down the road) might benefit the back end and implement terser in that environment

On the third goal:

  • I may just not be seeing it or be familiar enough with the MODX backend template, but it looks to me as if bourbon and bourbon-neat are not used in Revo. If that’s the case, remove these dependencies.
  • There is so little in the way of images (of any significant size) in the interface that running imageoptim seems like overkill. I’d suggest removing it.

For those more intimately familiar with this subject, especially the maintainers/code owners, please let me know your thoughts on this and any other suggestions you may have.

2 Likes

FYI, my PR to implement this has been merged into 3.0.0-alpha3. A couple of items from the above proposal were not included:

  1. Did not move to Webpack, as it was possible to achieve everything via grunt. May still be worth exploring in the future…
  2. Kept Bourbon / Neat, as they are in fact used for some of their grid features
2 Likes

Grunt is a task runner, webpack is a module bundler.
Also Grunt is not so popular tool in 2021; even Gulp is more popular, more fast and flexible task runner.

Rhetorical question: how is the MODX community going to attract developers using ineffective tools?

A few things to note:

  1. Yes, I wasn’t clear in my previous comments re webpack/grunt … right, the move on the task runner side would be to gulp. Webpack would be nice for creating area-specific bundles for resource editing, element editing, etc.
  2. The move made with my PR that was merged for 3.x gets us going in the right direction. Yes, the build process is still using grunt, but is now utilizing current tools to allow us to get into the current century, javascript-wise. It was going to be easier to get that done quickly within the confines of the current task runner. The next move would be to switch to gulp.
  3. Lastly, I’m in total agreement that the old tooling is going to dissuade some if not many developers, which is why I took it upon myself to start working on the build process recently. Progress has been and will continue to be made on that front. The big one for me now is Ext JS. It’s a great framework, but we’re stuck in a 10+ year old version of it and it’s going to take a major rewrite to get us up to date (whether it’s with Ext 7+ or another framework/set of tools).