Ink VS nestjs-commander

I've always wanted to build a CLI tool, and when I realized that you can build one using React with Ink, I converted my Python script into a CLI tool.

⚠️ Git for Windows Terminal is currently not supported, and the tool is limited to ink. We will look for alternatives later. Please use CMD, Vscode terminal's Git... terminal

There is a good solution for some of those cases - ink. With ink, I can implement text-based UI with knowledge of React, which is neat but there are still some caveats for my usages:

Looks cool, right? Building a similar UI in the terminal without any library would be quite hard, though, thanks to Ink it's almost as easy as building any frontend UI with React.

ink?

I'm writing a CLI with ink. Writing async code is important as to not block the rendering and respond to user input. I have a few loading animations that update every 100ms. Synchronous operations can make the animation hang for >500ms, making the animation choppy.

You get the comfort of using react components instead of fighting with HTML tables to make your emails look nice. I think it's awesome! It's analog to what ink[0] does with CLI outputs. Sure, you could write fancy CLI outputs in bash, but ink takes the pain out of it and makes it easy.

[0] https://github.com/vadimdemedes/ink

Due to Node's asynchronous behavior, it makes Node great for long-running processes that make a lot of HTTP requests, database calls, and other async ops, like a web server or a REST API. However, if I am making a CLI tool for pretty much personal use only, with very minimal async operations, then blocking the event loop with a synchronous function that will resolve almost immediately will make no difference perceivable to a human brain or have any speed benefits that someone can actually observe (think `fs.readFileSync` or `require('dotenv') of 10 line config file, or a quick embedded db (sqlite) query with only ~100 records. I'm wondering what the best way to implement the database part of the app synchronous. I can read/write to JSON files but it would be tricky because the data is relational, and some complex joins and other data wrangling operations are required (complex to perform in JS but are easy to implement in a SQL statement). It's not important what the operations are, that's not the point of this post. This is mostly a personal project of interest: making this CLI tool completely avoiding any async operations/using no promises. I would like to use node tho, as I said this is just out of interest and I also want to experiment with several CLI libraries such as Ink or Cliffy.

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