I think it's a well written bit of knowledge, even though it is written by an AI and posted by a human as intended satire. It's full of ideas, I hope the author does check back in and reports on how many AI PR's come out of it.
>Committing node_modules to your repository increases the surface area available for automated improvement by several orders of magnitude. A typical Express application vendors around 30,000 files. Each of these is a potential target for typo fixes
I'm not sure what layer of irony I'm in, but goddamn committing node_modules sounds awful regardless of AI.
Some projects like to vendor their dependencies so they don’t have to rely on the supply chain staying up and can create hermetic builds. Of course this prevents you from getting security updates and bug fixes but that’s the trade off.
I know someone’s going to say “you can lock the dependencies ” but this does not make it for sure that you’ll get a 1 for 1 copy of the dependencies again. Some node modules npm I internally or do other build procedures
"I know someone’s going to say “you can lock the dependencies ” but this does not make it for sure that you’ll get a 1 for 1 copy"
It doesn't. Node ecosystem keeps getting worse the closer you look at it.
At that point I'd shove the npm tooling up my ass and make a zip and hash it, with some simple instructions to retrieve it. Under no circumstance would I upload code from a dependency into the repo. Much less the dependencies of the dependencies.
Even if you are at the point where you are concerned about the vendor ceasing to exist and distribute the code, I would self host it and download it from my own url at build time.
Uploading the code is such a last resort move.
I don't think it's a trivial mistake, having a 50MB codebase and 500KLoc instead of 50Kb and 5Kloc, is a great way to force yourself and others to enter into 'make thing work' mode instead of 'understand thing' mode.
> At that point I'd shove the npm tooling up my ass and make a zip and hash it, with some simple instructions to retrieve it
This is basically what Nixpkgs does. Every NPM package depends on its NPM dependencies zip, and the hash of the dependencies is stored with the package metadata.
There was a post about github search here maybe a year ago, where I commented that the search often showed results from accidentally committed files like node_modules. They did seem to improve that.
Although I do wonder how much storage they're spending on it. There are a of student projects on github.
I don't think any of these will work because AI agents are not checking this data before working on the project. What you actually need to do is proper marketing and creating a funnel to attract AI agents to your project. The lack of contributions is from having a lack of funnel for entities to discover the project than metrics like open issues per contributor.
30 comments
- Disable branch protection
- Remove type annotations and tests
- Include a node_modules directory
Then, I went back to read the preamble. I can be a bit slow on the uptake.
>Committing node_modules to your repository increases the surface area available for automated improvement by several orders of magnitude. A typical Express application vendors around 30,000 files. Each of these is a potential target for typo fixes
I'm not sure what layer of irony I'm in, but goddamn committing node_modules sounds awful regardless of AI.
I know someone’s going to say “you can lock the dependencies ” but this does not make it for sure that you’ll get a 1 for 1 copy of the dependencies again. Some node modules npm I internally or do other build procedures
It doesn't. Node ecosystem keeps getting worse the closer you look at it.
At that point I'd shove the npm tooling up my ass and make a zip and hash it, with some simple instructions to retrieve it. Under no circumstance would I upload code from a dependency into the repo. Much less the dependencies of the dependencies.
Even if you are at the point where you are concerned about the vendor ceasing to exist and distribute the code, I would self host it and download it from my own url at build time. Uploading the code is such a last resort move.
I don't think it's a trivial mistake, having a 50MB codebase and 500KLoc instead of 50Kb and 5Kloc, is a great way to force yourself and others to enter into 'make thing work' mode instead of 'understand thing' mode.
> At that point I'd shove the npm tooling up my ass and make a zip and hash it, with some simple instructions to retrieve it
This is basically what Nixpkgs does. Every NPM package depends on its NPM dependencies zip, and the hash of the dependencies is stored with the package metadata.
NPM is awful.
Although I do wonder how much storage they're spending on it. There are a of student projects on github.