Over the last several months I built Tyr, a TypeScript-native CLI framework designed for internal team tooling. It started as my final year thesis project. It’s now at a point where I think it’s genuinely useful, but I know there’s a lot of room to grow, and I’d rather grow it with input from people who’ve solved these problems longer than I have than pretend I’ve got it all figured out.
The problem I was trying to solve
If you’ve worked on a team for a while, you’ve probably seen this pattern: a scripts/ folder full of shell scripts and one-off Node utilities, each written by a different person, none of them tested, half of them undocumented, and nobody quite sure which ones are still safe to run. Every team seems to reinvent this, slightly differently and slightly worse each time.
Tyr is my attempt at giving that mess some structure, without forcing teams into a rigid, opinionated tool they can’t adapt.
What it actually does
Every command in Tyr is a plain function that receives a fully-wired context object:
export default ({ task, fail, git, logger }: TyrContext) => {
return async (args: string[]) => {
const branch = await git.currentBranch();
logger.info(`On branch: ${branch}`);
};
};
Enter fullscreen mode Exit fullscreen mode
No manual wiring, no boilerplate. Git, shell, filesystem, Docker, SQL access and more are injected automatically through dependency injection. A few pieces I’m particularly happy with:
- tyr doc: generates a live, browsable reference from JSDoc comments across your whole toolkit, so new team members aren’t hunting through source files to understand what a command does.
- A module system: teams can package and share commands via a manifest.json, installed with tyr –add , without needing to publish anything to npm.
- Fork-and-own by design: the whole project is meant to be forked and republished under your own npm scope in a few minutes. It’s not a “please don’t fork this” project, it’s the opposite.
npm install -g @tyrframework/cli
tyr --config [--repo <remote-github-url>]
Enter fullscreen mode Exit fullscreen mode
Why I’m posting this here instead of just shipping it quietly
Honestly, I don’t think I’m the right person to decide what Tyr should become next. I built this to solve a problem I personally kept running into, and it went further than I expected, but I’m one developer with one set of experiences. There are almost certainly DevOps patterns, edge cases, and better architectural decisions that people who’ve been doing this longer than me would spot immediately.
So this isn’t a “look what I made” post. It’s closer to: I made something that might be useful, and I’d rather it grow through other people’s real-world use than stay exactly as I designed it.
License
Tyr is free and open-source software under the MIT License. You can use, modify, and redistribute it freely, including in commercial projects, without asking permission.
Where I could genuinely use help
- Trying it on a real problem you have and telling me where it falls short. That feedback is worth more to me than any feature I could think up on my own.
- Reviewing the architecture. If dependency injection in a CLI context is something you have opinions about, I’d love to hear them, including “this part is over-engineered” or “this part is under-engineered.”
- Writing a Manager or module for something Tyr doesn’t cover yet (Kubernetes, cloud providers, whatever you actually use daily).
- Pointing out what’s missing in the docs. I wrote them, so I have blind spots about what’s actually confusing to someone seeing this for the first time.
There’s a CONTRIBUTING.md with setup instructions and a few good first issues if you want somewhere to start, but honestly, even just trying it and opening an issue saying “this was confusing” or “this broke” is genuinely valuable to me.
Repo: https://github.com/TyrFramework/tyr
Docs: https://tyrframework.github.io
Thanks for reading this far. If you give it a try, I’d love to know what you think, good or bad.
답글 남기기