We build assets via custom file tasks in
assets.rake
. Our build system is
based on esbuild. This is because esbuild is the fastest of the bundlers.
We used to use jsbundling-rails and
cssbundling-rails with the esbuild
opinion. We no longer do this.
This is mostly because both those gems now indiscriminately enhance the spec:prepare
rake task such that CSS and JS
are built even when running a single spec.
We avoid this by using the aforementioned file
rake tasks to symbolic application.js
and application.css
files
that have FileList
dependencies on the entire app/javascript
and app/assets/stylesheets
directories respectively.
CSS and JS will only build if any of the files in those lists have timestamps newer than their symbolic file.
- jsbundling and cssbundling only provide starter opinions via
install
templates for common frameworks ("I can get you started with esbuild for js" or "I can get you started with Tailwind for CSS", for example) which both only use apackage.json
script as an entry point - both gems imply a
rake
interface ofjavascript:build
orcss:build
and an associatedclobber
task which delegate to thosepackage.json
entry points. Thebuild
tasks are whatassets:precompile
uses in production, and theclobber
tasks are largely dev-only. - both gems enhance
spec:prepare
, which implies that we must build both CSS and JS on every single spec run if we accept the *bundling deal - It is easier simply never to enhance those tasks incorrectly (by removing the gems) than it is to remove and re-enhance them
- we have "symbolic"
application.js
andapplication.css
entry points which userake
file
tasks such that they aren't built on every run. We enhancespec:prepare
ourselves with those, and move thebuild
andclobber
tasks into our ownlib/tasks/javascript
andlib/tasks/css
.