Should I version control the minified versions of my jQuery plugins?

Question

Let's say I write a jQuery plugin and add it to my repository (Mercurial in my case). It's a single file, say jquery.plugin.js. I'm using BitBucket to manage this repository, and one of its features is a Downloads page. So, I add jquery.plugin.js as one of the downloads.

Now I want to make available a minified version of my plugin, but I'm not sure what the best practice is. I know that it should be available on the Downloads page as jquery.plugin.min.js, but should I also version control it each time I update it to reflect the unminified version?

The most obvious problem I see with version controlling the minified version is that I might forget to update it each time I make a change to the unminified version.

So, should I version control the minified file?

Answer 1

No, you should not need to keep generated minimized versions under source control.

We have had problems when adding generated files into source control (TFS), because of the way TFS sets local files to be read-only. Tools that generate files as part of the build process then have write access problems (this is probably not a problem with other version control systems).

But importantly, all the:

• tools
• scripts
• source code
• resources
• third party libraries

and anything else you need to build, test and deploy your product should be under version control.

You should be able to check out a specific version from source control (by tag or revision number or the equivalent) and recreate the software exactly as it was at that point in time. Even on a 'fresh' machine.

The build should not be dependent on anything which is not under source control.

Scripts: build-scripts whether ant, make, MSBuild command files or whatever you are using, and any deployment scripts you may have need to be under version control - not just on the build machine.

Tools: this means the compilers, minimizers, test frameworks - everything you need for your build, test and deployment scripts to work - should be under source control. You need the exact version of those tools to be available to recreate to a point in time.

The book 'Continuous Delivery' taught me this lesson - I highly recommend it.

Although I believe this is a great idea - and stick to it as best as possible - there are some areas where I am not 100% sure. For example the operating system, the Java JDK, and the Continuous Integration tool (we are using Jenkins).

Do you practice Continuous Integration? It's a good way to test that you have all the above under control. If you have to do any manual installation on the Continuous Integration machine before it can build the software, something is probably wrong.

Answer 2

My simple rule of thumb:

Can this be automatically generated during a build process?

1. If yes, then it is a resource, not a source file. Do not check it in.
2. If no, then it is a source file. Check it in.

Answer 3

Here are the Sensible Rules for Repositories™ that I use for myself:

1. If a blob needs to be distributed as part of the source package in order to build it, use it, or test it from within the source tree, it should be under version control.
2. If an asset can be regenerated on demand from versioned sources, do that instead. If you can (GNU) make it, (Ruby) rake it, or just plain fake it, don't commit it to your repository.
3. You can split the difference with versioned symlinks, maintenance scripts, submodules, externals definitions, and so forth, but the results are generally unsatisfactory and error prone. Use them when you have to, and avoid them when you can.

This is definitely a situation where your mileage may vary, but the three Sensible Rules work well for me.