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

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. :-)

reply


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)


Great to hear! (Co-creator here)


Try disabling spellcheck, this has serious performance issues for content editable in recent chrome versions.

https://bugs.chromium.org/p/chromium/issues/detail?id=107671...


Oh, interesting. I'll try that. I feel like I've seen it on FF too, so I'm not sure if that's the problem.


Thanks for the mention, Sam! Great to have you and Yousef in the community.

BTW, we are already tinkering on some interesting stuff with the Rust port, too. :-)


Thanks! Sadly haven’t had the time in the last 6 months to continue working on what I was experimenting with. Hopefully will soon.


I’m a bit biased, but I think 2022 will be the year of Y.js.

What we’ve done or set up for the next year:

* The Y-Collective to fund more and more related projects, like slate-yjs: https://opencollective.com/y-collective

* The Hocuspocus backend you've discovered, which will become public in April or so

* A cloud offering we’re bootstrapping to hopefully get even more money into the ecosystem

* Y.js core support for the Tiptap editor (900k downloads/month), with a lot more advanced features coming next year

* More and more frontend libraries, like SyncedStore which was on the frontpage a few days ago: https://syncedstore.org/docs/

* The Y.js Rust port: https://github.com/yjs/y-crdt

Exciting times!


I agree with Hans, we are going to see an explosion of collaborative tools next year. And Yjs is best placed to enable them.

The ecosystem around Yjs with the Y-collective is so impressive.


CRDTs (and Y.js especially) will deliver what Google Wave promised. Not as a single unifying UI for communication, rather all existing apps can get collaborative power where it makes sense. And that is a game changer for me – as a user and developer. Exciting times indeed!


I’m biased into Yjs too and bet on it. Yjs Rust port and other simply not ready for the prime and won’t be for a while. Bindings and unsafe Rust is the road to hell


How do the performance and features of Yjs compare to Automerge?


https://github.com/dmonad/crdt-benchmarks

Not completely up to date I believe but it shows that Yjs significantly outperforms automerge.


It will depend on your use cases. Better to check updated roadmaps too. The final gap won’t be too big IMHO


I’m building one for Y.js. If you want to take it for a test drive:

$ npx @hocuspocus/cli


Creator of Hocuspocus [1] (which I’ll open source next year) here. You can use y-websocket [2] aswell. Hocuspocus is a (very nice) wrapper/API around y-websocket written in TypeScript.

https://hocuspocus.dev/

https://github.com/yjs/y-websocket


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

Search: