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

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

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.

Answer 3

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.