3 ms·

Yes, I am a big fan of checking in the build directory. We work on lots of little one-off apps that need to last for 5-8 years. Having the build dir in the vers

by xbryanx 11y ago

Yes, I am a big fan of checking in the build directory. We work on lots of little one-off apps that need to last for 5-8 years. Having the build dir in the version control makes it so much easier to fix things and update content years down the road. It insures us from things like npm (insert your package manager here) going away. Which I know sounds ridiculous, but try to re-download some essential Flash/Actionscript library from 2009, in 2016.

n0us 11y ago
I honestly assumed this was common practice and everyone did it this way. It also makes it easy for someone to clone the repo and run the app without having to download a bunch of npm stuff and figure out how to get the build tool working.
- davnicwil 11y ago
  To be fair, if you do it right then npm should be the only dependency, and then installing all other dependencies (locally) and running the build should be handled completely by npm and its scripts. If this is done well then installing and building can be as simple as running two or even one npm commands. There's not really much of a 'figuring out' stage, if you know npm and its common patterns. If the solution to the perceived complexity of the build is to just commit the built artefacts to source control, it's possible that's a warning sign that the build process itself needs to be better organised and simplified, and make better use of the build tools so they help rather than hinder a developer coming to the project for the first time. That's what they're there for.
- hjek 11y ago
  Unless any of the libraries are natively built with node-gyp.
ggordan 11y ago
Just wondering how you deal with all the extra noise in the diff. What happens when multiple people are working on the project, are you not constantly having to deal with merge conflicts? I feel like checking in the build directory makes the diffs pretty much useless.
- jdmichal 11y ago
  > Just wondering how you deal with all the extra noise in the diff. What happens when multiple people are working on the project, are you not constantly having to deal with merge conflicts? I feel like checking in the build directory makes the diffs pretty much useless. Why would you ever bother merging a build artifact? Those files should always be rebuilt fresh before committing. Just quickly do whatever to clear it from the conflict queue, merge the source as necessary, then rebuild. Commit the rebuilt version.

by xbryanx 11y ago

n0us 11y ago

I honestly assumed this was common practice and everyone did it this way. It also makes it easy for someone to clone the repo and run the app without having to download a bunch of npm stuff and figure out how to get the build tool working.

davnicwil 11y ago
To be fair, if you do it right then npm should be the only dependency, and then installing all other dependencies (locally) and running the build should be handled completely by npm and its scripts. If this is done well then installing and building can be as simple as running two or even one npm commands. There's not really much of a 'figuring out' stage, if you know npm and its common patterns. If the solution to the perceived complexity of the build is to just commit the built artefacts to source control, it's possible that's a warning sign that the build process itself needs to be better organised and simplified, and make better use of the build tools so they help rather than hinder a developer coming to the project for the first time. That's what they're there for.
hjek 11y ago
Unless any of the libraries are natively built with node-gyp.

ggordan 11y ago

Just wondering how you deal with all the extra noise in the diff. What happens when multiple people are working on the project, are you not constantly having to deal with merge conflicts? I feel like checking in the build directory makes the diffs pretty much useless.

jdmichal 11y ago
> Just wondering how you deal with all the extra noise in the diff. What happens when multiple people are working on the project, are you not constantly having to deal with merge conflicts? I feel like checking in the build directory makes the diffs pretty much useless. Why would you ever bother merging a build artifact? Those files should always be rebuilt fresh before committing. Just quickly do whatever to clear it from the conflict queue, merge the source as necessary, then rebuild. Commit the rebuilt version.