darcyclarke.me
@vlt.sh Founder / CEO
Prev: GitHub, npm & Themify Co-Founder
50 posts
1,600 followers
105 following
Regular Contributor
Active Commenter
comment in response to
post
The idea there being that you effectively make the end-user aware of & then responsible for their existence.
comment in response to
post
I've thought for awhile that clients should automatically generate an override/resolution/extension in the project root for mutable transitive deps. That would become the *only way* they'd be supported. You could then opt-out & effectively get rid of them (similar to transitive dev deps).
comment in response to
post
en.wikipedia.org/wiki/Uniform...
*Correction, "dots" *are* allowed: "...consisting of a sequence of characters beginning with a letter and followed by any combination of letters, digits, plus (+), period (.), or hyphen (-)".
Would still want to avoid known schemes: en.wikipedia.org/wiki/List_of...
comment in response to
post
Notably, I'm not crazy about the arbitrary `registry:` protocol fwiw (it was a carry-over/unrealized spec from npm). I much prefer the explicit/pre-defined custom registry protocol approach which I think you're leaning towards.
comment in response to
post
We added a `registry:<url>` spec which allows dots. Shorthand registry protcols though (ie. `<custom>:`) should likely never, given they're so similar to URI protocol defs & thus are easily parsed out by `new URL()` alongside file/git/remote counterparts docs.vlt.sh/packages/spe...
comment in response to
post
You can see/read more in our docs for the `@vltpkg/spec` lib: docs.vlt.sh/packages/spe... (which expects an options/config to be able to properly parse custom registry protocols)
comment in response to
post
I'm a +1 here & would love to see pnpm/yarn follow what we did.
comment in response to
post
The hypothetically safety mechanism here is that if a protocol isn't configured/well-known to the client then it should blow up noisily. All JS package managers just happen to support `npm:` today which begs the question why/why not allow allow alternative/custom registry protocol definitions.
comment in response to
post
FWIW - I'm the one that championed our support for custom registry protocols in @vlt.sh as a mechanism to avoid some of the pitfalls with dependency confusion/misconfiguration. The concerns raised about transitive references sort of fall flat for me knowing we all resolve git/remote transitive deps.
comment in response to
post
Notably, that's if you trust that the metadata/manifest being served to you is accurate (ie. blog.vlt.sh/blog/the-mas... <- this still exists for everything that isn't name & version on the npm registry).
comment in response to
post
Many hiccups - this thread: github.com/orgs/communi... has many folks voicing issues. There was/is a somewhat delayed rollout afaik. Basically, you're going to need to start fetching packuments if you want to avoid rate limits & find tarball refs (since attachments/include_docs are gone now too)
comment in response to
post
Interesting note that "on average, 25–35% of transitive dependencies are filtered out as unused". Seems less then I thought although this may be getting watered down/averaged out across ecosystems.
socket.dev/blog/introdu...
comment in response to
post
cal.com/darcy grab some time & let's catch up!
comment in response to
post
🔗 Modernizing JS Supply Chain Security: tinyurl.com/modern-2025
comment in response to
post
100% needs refinement for sure (got some great feedback) but I think we can make some quick improvements & even roll out a GHA to spin up envs to more fully validate this
comment in response to
post
`$ npx reproduce reproduce` 😉
comment in response to
post
yes
comment in response to
post
😈
comment in response to
post
p.s. you can totally do this yourself btw, the `<pkg>` arg is actually a package spec; ie. you can get super explicit or provide range grammars:
`$ reproduce semver@>=6`
`$ reproduce [email protected]`
comment in response to
post
I ran the checks on my own machine (mba) so I apologize I didn't scan the entirety of the registry... yet 😜
What may interest you is just the actual cached set of metadata from that run, so I just threw that into a gist for you:
gist.github.com/darcyclarke/...
comment in response to
post
If I understand your hypothetical, you're saying any git ref could potentially have malware that was not published into the npm package, which is valid no matter what but reproducible check **shouldn't** pass if building+packing fails to produce the same integrity as exists in the registry.
comment in response to
post
We'll likely fast-follow this with a GHA to spin up the envs for you & run the test (making it easy to quasi-"sandbox"). You'll want to control your own env if you're truly security conscious & don't trust someone else's CI/config to lock down the env.
comment in response to
post
/cc @jordan.har.band @notwes.bsky.social @naugtur.pl
comment in response to
post
🔑 Insights from checking the top 5k npm packages:
- only 3.72% (186) have "provenance" (which launched ~2yrs ago)
- 5.78% (289) are reproducible today & - with additional strategies (ex. yarn/pnpm etc.) - that # will only grow with no additional work by maintainers
comment in response to
post
You can read a deeper dive about this & the motivation on the @vlt.sh blog here: blog.vlt.sh/blog/reprodu...
comment in response to
post
You can read about it here: blog.vlt.sh/blog/rolling...
comment in response to
post
Follow the link in a browser, not the GH app & it'll filter to issues on overrides. Feel free to look up my CV if you need more validation on my insight
comment in response to
post
github.com/npm/cli/issu...
comment in response to
post
npm's overrides are broken in *many* ways
comment in response to
post
Amazing conference so far here at @halfstackconf.bsky.social in PHX