It’s OK to put compiled front-end assets in git
There’s a debate going on about whether it’s a good thing to commit compiled CSS stylesheets and JS sources (in git or any version control system). You know, the files generated by SASS, Babel, Webpack, TypeScript, Elm, CoffeeScript, and hundreds of other compilers.
I think it’s perfectly acceptable.
One of the main causes of web services breaking is when they need to be redeployed, following a change in hosting or the webops deployment stack, or maybe a bug has been fixed in the application. In many cases, nothing to do with your app’s CSS or JS. Recompiling source code with lots of dependencies often fails when you have not touched it in a while.
Current front-end stacks can be complex: if you use anything that compiles to CSS or JS you’ll have to install those stacks for deploying the app. Often, you’ll need npm, which requires node (until recently the version of node that was available in Debian was far behind the direct download). You’ll be downloading a lot of npm packages. Sometimes one of them will require Ruby, or something compiled from C. Some of those dependencies will break eventually, and it’s often a lot harder to fix than your own bugs. And it’s likely you won’t be the person who has to fix it.
It also makes it painful for developers who want to work on the site but don’t want to touch front-end stuff, because they want to fix a bug, or scale up the app by adding a cache or a message queue.
Compiling assets can also make deployment quite slow, which is annoying in a continuous integration setup.
If you commit your app.css and app.js files, you have none of those problems. You’ve written perfect front-end code, which will work forever, and so you’ve left the company. But eventually the backend breaks and no one involved in fixing it wants to have to rebuild the front-end. Well, they don’t have to. Just commit the files.
Common arguments against commiting compiled code include:
“git is for source code, not compiled code”.
True, but the version control system you use shouldn’t impose constraints on how you design your app.
There are things like git-ftp that are meant to help avoid committing compiled code, by copying it from your local machine to the production server. Not very good in modern deployment contexts, though.
If you write an app using any web framework like Rails or Django, many files that are automatically generated will end up in your repo, and will break the principle that what you commit should be the code you write. (I’d like to see a framework whose autogenerated files are put in an git-ignored directory, leaving just your code to be committed. I’m not aware of one)
It’s bad to commit big files. Managing their diff has no interest and they pollute your git-diffs.
That’s true. But if your compiled assets are huge files, you’re doing something wrong anyway. It often leads to long page-load time, as well as rendering or time-to-interaction.
I don’t find that diff is a problem, git diff takes a path as an argument anyway, so I never see compiled-file diffs as long as they’re put somewhere separate.
Hope this helps.