What did I do...
- Used webpacker gem in Rails 5.x, and then checked all the webpacker/js packages into git that were installed by yarn.
- Compiled Rails assets, while still in dev, and checked them into git.
Why did I do it?
- For Webpacker/Yarn, even though it has a yarn.lock file and such, I didn't see a reason not to. Although you could make 100 reasons for this being 'wrong'. Plus, outside of our macs, gaining access to the outside world, installing yarn, etc, was close to impossible(well not impossible, just probably not worth it if we had another way). So if we were to develop anywhere outside of our macs, we'd have issues...of course, we wouldn't be able to download new packages anyway at that point if not on our macs...hmmm
- For the Rails assets, since yarn install and webpacker:compile is now 'baked in' to the rake assets:precompile command, we were stuck. It is a monumental task to get yarn/node installed past our dev environment.
How to make this work with precompiled assets in git and still develop like normal with uncompiled assets.
- The webpacker install and actually using it can be found on the webpacker github page.
Force development and test to still use uncompiled assets as normal.
- Inside the config/environments/development.rb and test.rb add config.asssets.prefix directive to override the defaults:
# this allows us to precompile for non dev and commit, yet still use uncompiled for dev
config.assets.prefix = '/dev-assets' # can be anything really
- How this works: since we will compile to the usual assets path, development and test will not find compiled assets and will default back to the uncompiled ones.
If assets change, now you need an extra step before checking into git:
- Note: Do this After running tests...this part is important as I've seen the manifest.json get overwritten and pointing back to the webpacker local server on port 8080.
- In your terminal:
RAILS_ENV=production rake assets:precompile
- Submit files into git as normal. Since production env is setup by default when webpacker is installed, that is the optimal env to use for this, even if you have more than one type of 'production' environment. Of course there are some that would say you should just have 3 environments in rails and use ENV vars to control everything else...depends on your setup/perspective, but I digress...
Conclusion/Thoughts:
This seems to be working so far, although there are some that would say I am breaking some cardinal rules of yarn/assets/etc, and some that probably say 'yeah I did that too'. All I know is we needed a solution for the closed environment our apps live in, and this seemed to be a viable solution. I didn't come up with this solution on my own, a bunch of googling, reading rails docs, and putting it all together here... I hope this spurs some fruitful conversation and perhaps a more elegant solution than this one for the closed from the outside world/hard to get anything installed outside development/using your own infrastructure and not AWS/Heroku world.
One other thing to mention...I believe this will help ease any transition we have into docker as well. I've seen some strategies for compiling and maintaining assets for docker, and they all seem messy. I believe this one will keep the docker image immutable and provide us with less friction between environments.
Top comments (0)