Hacker Newsnew | past | comments | ask | show | jobs | submit | hanspagel's commentslogin

How does such a post land on the frontpage :)


We basically do the same for https://github.com/scalar/scalar/

Publishing to npm, PyPi, Maven Central, crates.io, NuGet… all using changesets.


I mean, speaking as an oss maintainer, there is an infinite list of things msft could do on npm and gh to make our lives better, but we might just have to accept that we’re on our own and have to deal with those platforms mostly as they are and dependency cooldown is just a pragmatic approach. :)


100% management is gone, engineers took over


You can’t unpublish a npm package with more than 100 downloads I think.


The policy is https://docs.npmjs.com/policies/unpublish

    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.


Looks like Anthropic called in a favor and it's removed now.


Ah, another you can’t, but they can.

I’m still a little humored over peak web3 and the DAO / soft contract nonsense. Like in order to stop fraud entire coins were forked…


Sure you can, if you have a legitimate case you can ask npm to unpublish and they handle things manually :)


I have had to do this, well over a decade ago now, when working at a place that was a pretty big deal in the node world, and node was still pretty new. They helped us.

I would imagine GH would do the same if its a high enough profile issue.


Yep, we had to do this recently with Renovate, where we had too many releases, and new publishing hit a size limit on the registry, so we needed support to help us unpublish a load of old releases


The novel Red Team Blues involves a similar plot with a crypto token that's supposed to be immutable. It's pretty entertaining.


Good luck with that.


If I understand correctly, the plan is to add a virtual state to address this.


I think you’re looking for Laravel, with its many many official packages and the thousands of community packages, which are often full features including an optional frontend for it. :-)


From what I see, this does not help with pinning the dependencies and it doesn’t verify the downloaded action has the same content as it used to have. In other words, this is a tiny patch on a big wound.

We use commit hashes to pin actions, have the version as a comment (e.g # v4) and renovate will keep both up to date in the PRs.

And there is a more or less recently added repository setting to require actions to be pinned to hashes.


This is the way to do it.

Pin by hash.

Verify that the actions themselves aren't pulling in unpinned dependencies from Actions, NPM, or elsewhere.

Have a CI job or bot create PRs for new versions. Verify those PRs before merging.

If any particular action becomes a recurring chore or risk, consider if you should keep depending on it.

If you do these things, the "we need a package manager" is moot and most if not all of the concerns in that blog post don't affect you.


I don’t want to throw process at the problem. I think GH should provide a better system not the developers locking down dependencies and adding extra processes and steps to update the CI via a PR workflow. Not like PRs became the development bottleneck anyways for a lot of development teams these days. I wonder how we functioned 15 years ago with trunk based YOLO development. I also think that it wasn’t the best idea to base versioning on mutable branches and not introduce a registry in the middle. Think about it. The whole system is build on node anyways. But we pull “dependencies” via a weak git clone system.


How does this lock down transitive dependencies? Is it effective if the action you rely on doesn't pin its dependencies?


You don't use actions pulling in unpinned dependencies outside of trusted distro package manager at runtime.

I believe this problem is probably overstated. Can you point us to such an action you are concerned with that has either transitive actions dependency or unlocked npm dependencies where maintainers aren't responsive to addressing PRs to illustrate?


That’s actually an issue with the syntax highlighting in brave. :-(


Thanks gilli! Great to have you in the community. (Tiptap co-creator here)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: