Its unclear whether there is sufficient human authorship in cc for copyright to stick on a court. Anthropics arguments would hinge on the curation of plans and the direction decisions, which haven't been properly tested as the source of authorship yet. Typically contracted implementers sign over copyright to the project owners, and this is where there is case law.
Packages published less than 72 hours ago
For newly created packages, as long as no other packages in the npm Public Registry depend on your package, you can unpublish anytime within the first 72 hours after publishing.
There are 231+ packages that depend on this one, and I imagine they mostly use permissive enough version ranges that this was included.
Respecting instructions around tool use, even on small codebases, where the tool isn't its favourite way of doing things.
For example, models repeatedly try and not use my Makefile's (build / run / test / test-file / check) and instead spend several cycles attempting to invoke using system tools and getting it wrong.
I've got to the point where I run most models with an extra path folder which overrides typically bad commands tells them off and redirects them back (more effective and portable than hooks). But then sometimes the model reads the makefile, discovers the workaround, and does the stupid anyway.
Even putting "ggrep not grep, gsed not sed" (on a Mac with old default tools) in ~/.claude/CLAUDE.md isn't solid. Tool-use hooks to block the wrong tools and suggest the newer ones sorta works.
yarn with zero-installs removes an awful lot of pain present in npm and pnpm. Its practically the whole point of yarn berry.
Firstly - with yarn pnp zero-installs, you don't have to run an `install` every time you switch branch, just in case a dep changed. So much dev time is wasted due to this.
Secondly - "it worked on my machine" is eliminated. CI and deploy use the exact same files - this is particularly important for deeply nested range satisfied dependencies.
Thirdly - packages committed to the repo allows for meaningful retrospectives and automated security reviews. When working in ops, packages changing is hell.
All of this is facilitated by the zip files that the comment you replied to was discussing, that you tangented away from.
The graph you have linked is fundamentally odd. Firstly - there is no good explanation of what it is actually showing. I've had claude spin on it and it reckons its npm download counts. This leads to it being a completely flawed graph! Yarn berry is typically installed either via corepack or bootstrapped via package.json and the system yarn binary. Yarn even saves itself into your repo. pnpm is never (I believe) bundled with the system node, wheras yarn and npm typically are.
The way to do this today is to do it outside of node. Using an overlay fs with the overlay being a ramfs. You can even chroot into it if you can't scope the paths you need to be just downstream from some directory. Or, just use docker.
yes and no. Waiting 40mins for every test run is pure pain, platform specific ramfs type mounting is quite scriptable. Yes some devs might need to install a dependency, but its not a complex script.
I had to laugh, because the post you're replying to STRONGLY reminds me of this story, https://news.ycombinator.com/item?id=31778490 , in which some people on the GNOME project objected to thumbnails in the file-open dialog box because it might be a "Security issue" (even though thumbnails were available in the normal file browser, something those commenters probably should have known about, but didn't, but they just had to chime in anyway).
reply