Hacker News new | past | comments | ask | show | jobs | submit login

Interesting approach of basically providing a meta-layer on top of existing tools.

Do you have an example of how you inject context into the codemods? The approach we've taken at Grit is two-fold:

1. When something must be addressed (ex. `todo`), we have functions that wrap messages into the source code to ensure anyone sees the info until it's fixed. We pick up these messages automatically on our SaaS platform.

2. For non-blocking comments, we have a `log` function that any query can call to surface info into the result stream on the CLI + pull requests without it ending up in the final PR.

>4. all of today’s codemod libraries are for one language, so they are hard to orchestrate for a single project.

This isn't entirely true! Grit, my project, was built to be multi-language from the start: https://docs.grit.io/language/overview

[0] https://docs.grit.io/language/functions#todo




Grit looks cool! My apologies for the omission, I was unaware of it. I could have anchored too hard to the word "codemod" in my searches. Your tool looks awesome!

> Do you have an example of how you inject context into the codemods?

When you say "context", I want to make sure we're talking about the same thing, and the question makes me think we're not there yet. We're basically saying that storytelling about the changes is very important, so we bake invariance into the APIs of codemods themselves, so codemod authors are forced to provide descriptions, reasons, justification -- whatever -- at the key points.




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

Search: