Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Manifest mashup opportunity with Socket Registry #174

Open
jdalton opened this issue Oct 17, 2024 · 2 comments
Open

Manifest mashup opportunity with Socket Registry #174

jdalton opened this issue Oct 17, 2024 · 2 comments

Comments

@jdalton
Copy link

jdalton commented Oct 17, 2024

👋 Socket.dev dev here. Also, the Lodash guy (please replace it with whatever promotes builtin stuff and simplicity). At Socket we've released the Socket Registry as a place to catalog our growing collection of overrides. We also have a @socketsecurity/registry package that exposes our manifest.json. I really like the idea of sharing and where possible consolidating. So figured you might be consume our manifest.json or give pointers to what kind of data you'd like tracked to make it more useful for others to consume.

@43081j
Copy link
Contributor

43081j commented Oct 19, 2024

Interesting work you are doing for sure

So if I understood correctly, you do very similar to this repo but we use codemods while you use overrides

The actual detection and manifests are very similar I think

There should be some way we can work together, otherwise it is a lot of duplicated work. I'll have a think but it may also be worth us having a catch up call around this one day

@jdalton
Copy link
Author

jdalton commented Oct 20, 2024

@43081j

Interesting work you are doing for sure

So if I understood correctly, you do very similar to this repo but we use codemods while you use overrides

Yes. Codemods are where I'd like to go eventually. While evaluating solutions a few months back the wiring to replace the code wasn't in place (in this or another project that consumes this). The overrides route was a more ready-to-go approach as package managers support it out of the box.

There should be some way we can work together, otherwise it is a lot of duplicated work. I'll have a think but it may also be worth us having a catch up call around this one day

Great! In the meantime I'm taking inspiration from some of your field names (like "moduleName") and schema stuff (may help folks consume it) to align more closely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants