@nick-mazuk/cli v1.0.8

Monorepo cli

Goal: Create, develop, and maintain a monorepo with ease.

Features

• Publish packages to npm
• Feature flags
• Internally sharable libraries
• Code owners

Goals

These are mostly stretch goals. No idea how possible they are, but I'm aiming for them.

• Linting/testing should always be 5 minutes or less

FAQ

What are the design philosophies?

• O(1) development time: Ideally, as the monorepo grows, developer time should not. Performance is not a nice-to-have. It's a must-have. You won't always achieve O(1) performance, but strive to get as close as possible.
• Less is more: The less code you write, and the more code you delete, the better.
• Predictable: Developers should be able to predict the CLI's API. Complexity is ok as long as you can accurately predict what to do.
• Simple: Always choose simple when all else is equal. This can help with predictability.
• Collaboration: Code is meant to be collaborated on. Therefore, collaborative coding should be a first-class citizen.
• Automate everything: If it can be automated, automate it.
• Through limitation there's freedom: By enforcing smart defaults, we can make assumptions that improve performance and developer experience. If there's a structure for doing things, we can even eliminate lots of boilerplate.
• Write from scratch: Unless there's a really good reason not to, write everything from scratch. This allows for larger optimizations, less unused code, and better user experience.

What's the scope of this monorepo?

In short, I'm aiming to streamline the entire process of writing JS code, including creating new projects, to testing, building, publishing on npm, deploying, etc. If it's part of a standard JS workflow, this CLI will probably help.

Exact feature set and API are yet to be determined.

Though note that this CLI is opinionated and not all workflows will be supported. I'm aiming to create the ideal workflow. Therefore, it may be incompatible with how you currently work.

Will X be supported?

Currently, I plan on supporting:

• pnpm (not npm or yarn)
• ES Modules (not commonjs)
• TypeScript
• Sveltekit
• Jest?
• Cypress?

Depending on how much I like Go, I may also support Go packages as well. Then, I can have everything in one monorepo.

Why is this written in Go and not JavaScript?

While this monorepo is going to focus on JavaScript projects initially, Go is much faster at scale. Tools like esbuild have shown that JS developer tools don't need to be written in JavaScript, leveraging much faster performance than JS ever could. Plus, I want to learn Go.

Is this production ready?

No. I'm not even using it yet. Consider this in experimental. Many features are missing. API's may change at any time. And the overall structure of the monorepo will likely change.