nestjs-commander VS nx

To echo the other's here, Nx has been an amazing dev experience for me! I use it for ogma, for nest-commander, testing-nestjs, and for nest-samples and @nest-lab/, all using pnpm as a package manager.

This absolutely isn't true. I'm both on the core team and a maintainer of several open source modules for Nest (nest-commander for CLI creation, ogma my own logger that has a really powerful interceptor, nestjs-spelunker which can print out an object representation of your Nest application and help with module debugging for dependency resolution, and a few more). The command module is even featured in the docs.

4) Nest is great for architectural consistency, but one drawback of the framework is boot time. It's nowhere near as bad as Spring or .NET, but it is much slower than a standard Node or Express server. Though, the new Lazy Loading does help to alleviate some of that pain. Running nest in serverless environments does take extra setup, but it is usable, and packages like nest-commander make it viable for CLIs too. Personally, I pretty much don't write Node applications if they aren't in Nest unless I'm writing super rough prototypes. Typescript has become a must for any long term application, and the structure Nest brings outweighs just about any downsides I've seen from it

I work with the NestJS framework a lot and ended up writing nest-commander as a commander wrapper for NestJS, so my CLIs and servers can use the same framework. Lately I've been working on adding in plugin support too.

Overall, I'm pretty excited to have this flow automated and working through three of my favorite package management tools. Everything will also work if you're using a yarn workspace instead, just change the sed script to modify the workspace file for yarn instead of the one for pnpm. I'm currently using this for my ogma and nest-commander repositories, feel free to have a look if you need some inspiration and/or real life examples. If you're developing packages and using an Nx workspace and need automated package deployment, give this a shot.

There's also packages like nest-commander (disclaimer: that one is also mine) for making CLI applications instead of HTTP servers.

I've used Express, Fastify, and NestJS for the most part. I almost exclusively work with NestJS now, as you can imagine. The fact that it has an opinionated structure for how to architect your application is something that drew me in to begin with. With almost every Nest application I can pick it up, scan the structure, and have a good idea of what's going to be happening at a very high level. It also has defined classes with specific roles. A guard will always be used for authentication, a pipe will always be for transformation and validation of request information, a filter will always be for error handling. The only one that doesn't have a "this is always for that" is an interceptor, which is pretty much your middleware of the Nest world. Logging, caching, response mapping, it can do it all. There's also using Nest for more than just web servers, as there's nest-commander (one of my packages) for CLI applications, and there's discord bot packages for Nest as well.

Overall it looks pretty good. I prefer having each class as it's own command line how nest-commander does it, but this seems to be a pretty good alternative

There's two underlying packages, one for either HTTP adapter, @nestjs/platform-express and @nestjs/platfoorm-fastify. Both of these have HttpAdapter classes that implement the abstract HttpAdapter that Nest uses as a main interface. Nest doesn't actually need the adapters to run either, you can make a microservice application that doesn't have any HTTP components, or even CLI applications with community packages (disclaimer: that one is mine). Nest is really there to help provide the modular system and help with architecture (in my opinion).

For more information on the project you can check the repo here. There's also a testing package to help with testing both the commander input and the inquirer input. Feel free to raise any issues or use the #nest-commander channel on the official NestJS Discord

Hono does have a template application for Vercel, but in my case, my requirements were different (aren't they always 😅). I was working in a monorepo (using nx) because I wanted to manage my libs, tests, and examples all together in a single place, instead of having different repos.

Recently, My coworker is using Nx to automate his workflow, including automated release using semantic version. I found this method quite useful, so I want to re-implement on single GitHub repositories (without Nx).

I started a discussion on GitHub concerning that subject: Design Nx Plugin Project Crystal

Nx

We are looking for companies to partner with on the Analog project to support development of the project. Thanks to Snyder Technologies for being an early adopter and promoter of Analog, Nx for joining us as a sponsor, House of Angular, and many other backers of the project.

Additionally, thank you to all our community launch partners across the frontend ecosystem for helping us bring Storybook 8 to the world! Thanks to Chromatic, Figma, ViteConf, Omlet, DivRiots, story.to.design, StackBlitz, UXpin, Nx, Mock Service Worker, Anima, Zeplin, zeroheight, kickstartDS, and Kendo UI.

The advent of esbuild, the native support for ES Modules in browsers, the widespread adoption of import map, the emergence of tools like Native Federation, and the Nx ecosystem all combine to forge a flexible and well-maintained Micro Frontend Architecture.

Nx is a set of DevTools to make it simpler for software dev teams to work within a monorepo, which is a version-controlled code repository that contains several projects. Think of Nx as a VSCode of build tools.