Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
What would the pros and cons of storing the compiled CSS output of SASS in version control?
If one is using SASS to build a websites CSS and using version control one can either,
- Keep both the SASS and the resulting CSS files in version control.
- Only storing the SASS files in version control.
What would the pros and cons of each method be?
4 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
One thing to consider if you decide to store the CSS in version control is how to make sure that the CSS is always updated whenever the SASS is updated. (Of course this is true of the more general question, not just about CSS and SASS.) My preferred way to do that is to add a pre-commit hook to the project that runs the build scripts for any built files I'm keeping in version control.
The nature of the pre-commit hook will depend on what version control system you're using. If you're using Subversion, for example, you can add the hook to the Subversion server; if you're using Git, you could just add the hook into your .git/hooks directory manually, but I'd recommend using a tool like Husky so that anyone else who works on your project will get the same hooks.
So to answer your question directly: one con of keeping derived files in version control is having to set up the above, or possibly letting your derived files slip out of date with their sources.
0 comment threads
One of the benefits of having the compiled CSS in the revision history is that it enables you to see changes if you have other steps in the compile process besides SCSS -> CSS. One example is if you use auto-prefixer, which automatically adds vendor prefixes to CSS in order to support your target browser versions and ensure adequate market share coverage (see Can I Use). There are all sorts of PostCSS plugins available.
With the example of an auto-prefixer, the SCSS code doesn't have to change for the output to change. If a browser updates, the CSS might update. If the users switch from one version to another, that could change the browsers or versions you might prefer to support. If your SCSS doesn't change, but the CSS does, it's preferable to have the CSS in the revision history.
Another benefit of revisioned CSS is that you can include compiler comments in the CSS output that show what line and file in SCSS each CSS line came from. This speeds up the debugging process if you have an issue occur or make a mistake. And if you ever need to revert your code changes, you don't have to wonder what the resulting CSS you get on your production environment will be.
0 comment threads
I follow a principle of only including in version control source code. If I can reliably generate the same output from the same input from that source code then there is no need to also store the final build artifacts themselves.
As long as your are also storing your build configuration in source control alongside your SASS files, you should be able to reliably regenerate the CSS from any point in your project's history.
The reason I follow this approach is because it forces me to ensure that the source can be reliably built by others and isn't accidentally dependent on a local dependency anywhere. This is important in OSS but also in private repositories where there is some collaboration with other users. If my build toolchain has to build this from scratch, I've got at least some validation that others can do the same.
Another advantage is that this approach keeps my repository as simple and lightweight as possible but this is more relevant when dealing with large outputs and less a problem in the case of CSS.
If you do store your build output in source control, it may make deployment much faster since the implication is that you have already performed your build locally. If you do do this, like @r~~ recommends in their answer, you should consider automating your build step to always build before publishing changes to ensure the source and output are never out of sync.
0 comment threads
This is as old as the ages, and the problem existed in the Yacc world long before CSS was invented.
Keep both the SASS and the resulting CSS files in version control.
Good: More predictable, easier to handle deployment. Less toolchain is necessary for building. Fewer dependencies for certain users.
Only storing the SASS files in version control.
Good: Saves space.
Useless trivia, but amazing: currently Bison kind of advices shipping generated *.c docs along with source *.y docs.
0 comment threads
0 comment threads