Should I commit a generated .versions file?

help
1

After publishing my Meteor package, I noticed that a .versions file appeared.

$ cat .versions 
base64@1.0.3
binary-heap@1.0.3
callback-hook@1.0.3
check@1.0.5
csats:libxmljs@1.0.0
...

Should I commit this file?

1 Like
2

Yes you should. That file makes sure that meteor builds are repeatable across machines and platforms.

Check the already pre-generated .gitignore file in that directory for files/directories you should not commit.

1 Like
3

To clarify, I’m talking about the top-level directory of a Meteor package with binary npm packageshttps://github.com/csats/meteor-npm-libxmljs. The .versions file appeared in the topmost directory after I ran meteor publish-for-arch. There’s no autogenerated .gitignore file in the top-level directory.

1 Like
4

Yes. For the same reason as @serkandurusoy already said. :wink:

2 Likes
5

Sorry, I thought you were referring to the one generated by a meteor project, but the answer is still yes, the .versions file is there to ensure consistency.

1 Like
6

I know this is old, but one annoying thing I’m finding about committing the versions file is that if you use --extra-packages in development, for example I don’t want to use hot code push in production (for various reasons) but I do like it in development so I can see changes easily, so I pass the following to meteor in development and don’t add these packages in the packages file:

--extra-packages hot-code-push@1.0.4,reload@1.3.0

The issue is this updates the versions file in development which git then sees as a change. So I always have to take the the temporary “development” packages back out of versions or I risk committing it with those packages in it. Which I guess is fine for development.

But when deploying, the build process looks at the versions file right? So if I forget to make that update, now I have packages in production that I don’t want.

The whole --extra-packages and versions relationship seems clunky.

If you don’t commit the versions file, then you risk developers not building your project correctly due to version mismatch.

Am I understanding this correctly?

7

It looks like when deploying to Galaxy, it actually checks your packages file again and doesn’t go straight off of your versions file. So whatever was added to your versions file by --extra-packages in development gets removed before deploying.

So it will again update your versions file without your --extra-packages and thus cause another change for git to notice but… it doesn’t really matter which versions gets committed as far as --extra-packages is concerned. Because whether you’re running in development or in production, it will load the correct packages no matter whats in the versions file.