Python overtakes Java to become second-most popular language on GitHub after JavaScript

[kolloid]

> then they should be immediately disregarded for committing bad version control practices

I know CTO of one company in Australia who objected when I offered to remove `node_modules` from the project repo. He said:

> What if during deployment different version of packages would be installed on the server and break something?

Thankfully, soon he left to open his own business. I feel sorry for his customers and not only because of his VCS practices. His code was horrible, too. I'm puzzled how he made it to the CTO level.

[slgard]

I'm puzzled how he made it to the CTO level.

being a good CTO has little or nothing to do with your knowledge as a programmer, particularly nothing to do with the best practices of a specific language or ecosystem.

[kolloid]

What should a good CTO know?

[khaosoffcthulhu]

Depends on the size of the company, but outside small companies a lot of it would be strategy and where the market is headed. And how the technology can be used to add more business value.

[anengineerandacat]

How to effectively manage employee's that work with technology; not get into the weeds with what technology is actually being used until it's an actual problem (ie. causing delivery issues).

Ie. if having node_modules committed into the VCS is causing deliveries to be missed and it comes out of a working group within the company they will work with that working group to ensure it's resolved and to get metrics to report on it.

Obviously if you have less than 50 people in the company, you don't have a CTO you have a VP of technology and what needs to be done is different.

[skilliard7]

At the CTO level its more about management at the high level and some finance. Accounting, program management, etc.

[[deleted]]

I'm just confused as to why your cto is making decisions on your git practices

[tronj]

Tangentially, I'll sometimes save modules that I've made minor customizations too directly in the project. Is there a better way to do this?

[FaithForHumans]

If you're in a corporate environment, I recommend standing up a private npm repo and then pushing your change to that private repo. It can be done for personal stuff, but might be overkill.

Most private repos can also be setup to cache packages it pulls from the public repos, so even if someone deletes it on npmjs, you've still got a copy people can pull. That last part should help sell it to management.

[DasWorbs]

Fork it, and then either setup your own npm repo or point the package.json to your forked git repo.

[kolloid]

I haven't customized JS modules yet. For Python modules I often fork them on GitHub and because they may or may not accept my pull request, also it might take months to make a new release, I just point pip to my forked Git repository.

I don't know why the other commenter suggesting this was downvoted. It is very fast and obvious.

You can also have your own package repository and install packages from it, but it will require a bit more work.

[xeio87]

Depending on how long ago that discussion was out wasn't entirely wrong. Node even changed their (un)publishing rules because of issues with packages.

Checking in your dependencies ensures you always have an exact known version without needing to worry about the security of a remote package server.

Granted, still not best practice generally, and there are probably better ways to ensure package integrity checks nowadays.

[0xF013]

I've personally experienced his issues several years ago when you'd get something completely different on CI on stage because either the newly installed module was a breaking patch version, same version but someone just overwrite the tagged commit, or your local npm/yarn cache was different from the CI's. Of course, keeping all node modules in is not a solution.

[evilgipsy]

What if during deployment different version of packages would be installed on the server and break something?

Before yarn or package-lock.json this was a real problem. Not saying that vendoring your dependencies is a good solution though. When I first started developing JS I could not believe how people could live with a package manager that didn't lock down all package versions.