>To build a version of master, you have a gemfile / package.json that, if it follows specifications, will correctly tell you everything, down to the version, that should be installed.
You can set specific versions, but the default behavior is to do >= or ~ versions, at least in Node. But you could potentially go in and change the references to =version# to get a version closer to the one the developer built -- but even then there's no guarantee that the latest build hasn't had a more recent download of the packages, with newer versions than those specified in package.json.
But I didn't know this about go package importing. I'm a bit disappointed that they didn't at least make it possible to import @ a particular hash.
You could look at the last check-in and pull versions of each of the dependent repos as of that date, if the latest builds don't work.
>"experienced" and "NodeJS" don't go together so often in my book
Touche.
But I've encountered similar issues with Ruby, TBH (allegedly senior developers who turn out to be slow and not as experienced as I had hoped), and it happens that the JavaScript developers I have around me seem stronger than the Ruby developers. But more and more developers are training every year; I read one article that alleged that junior developers outnumber senior by a factor of something like 18-1 at this point. So I'm statistically likely to be surrounded by an insulating layer of junior developers no matter the language I choose. :)
If I type "npm install --save foo", it gives me "^1.2.3" which says "everything compatible with the current version".
If you don't follow semver specification and make incompatible changes, well, :(
You also have the wonderful npm shrinkwrap command (https://docs.npmjs.com/cli/shrinkwrap) which locks you down similar to a Gemfile.lock, but inline with how the npm world works.
Thanks for tooting your horn about being senior while also being factually incorrect about the default behavior of node and not knowing you can use shrinkwrap to leave the loose version specifications but also commit what they actually resolved to on your machine.
You can set specific versions, but the default behavior is to do >= or ~ versions, at least in Node. But you could potentially go in and change the references to =version# to get a version closer to the one the developer built -- but even then there's no guarantee that the latest build hasn't had a more recent download of the packages, with newer versions than those specified in package.json.
But I didn't know this about go package importing. I'm a bit disappointed that they didn't at least make it possible to import @ a particular hash.
You could look at the last check-in and pull versions of each of the dependent repos as of that date, if the latest builds don't work.
>"experienced" and "NodeJS" don't go together so often in my book
Touche.
But I've encountered similar issues with Ruby, TBH (allegedly senior developers who turn out to be slow and not as experienced as I had hoped), and it happens that the JavaScript developers I have around me seem stronger than the Ruby developers. But more and more developers are training every year; I read one article that alleged that junior developers outnumber senior by a factor of something like 18-1 at this point. So I'm statistically likely to be surrounded by an insulating layer of junior developers no matter the language I choose. :)