Ts.ED VS typescript-eslint

Ts.ED - Controller-based (DI supporting) backend framework that seems to offer quite a lot (although I'm wary of it being quite close to Nest.js)

Take a look at ts.ed. They have some similar feature

has anyone looked at tsed.io

As a developer, it's always important to find ways to streamline the development process and save time. For the past two years, I've been using Ts.ED as the framework for all of my applications and it's been a game-changer. Not only has it allowed me to gain back lost development time, but it's also been the foundation for my open-source project HighScore.

I use Ts.ed as framework, go to this site to known more about this awesome framework.

Because of this, I decided to create a base template of a REST API created with NodeJS, using Ts.ED as the base framework and TypeScript as the programming language. This template tries to follow the principles of Domain Driven Design and implements a Clean Architecture/Hexagonal Architecture to try to rely as little as possible on the infrastructure and the framework while keeping in mind at all times the language and the needs of the business logic.

I love Ts.ED https://tsed.io

I'd also love to shout out Ts.ED which is another great Typescript framework that I've written production applications with. It's a natural fit for anyone who loves .NET applications, it's why I chose it.

Typescript-eslint can assist in this task. This tool helps identify all instances of unsafe any usage. Specifically, all usages of JSON.parse can be found and it can be ensured that the received data's format is checked. More about getting rid of the any type in a codebase can be read in the article Making TypeScript Truly "Strongly Typed".

> Only lint files that have changed? How hard that is?

Quite hard, especially since type-aware rules from e.g. https://typescript-eslint.io/ mean that changing the type of a variable in file A can break your code in file B, even if file B hasn't changed.

The article only touches this: when converting to TypeScript, `any` is useful, but in the end you don't want this type in your codebase - so don't forget to use typescript-eslint [0] and turn on those no-unsafe-* rules which guard against `any` leaking into your code.

[0] https://github.com/typescript-eslint/typescript-eslint

By convention, React components should be named in PascalCase. @typescript-eslint has the config we need, and though we can't specifically target React components, we can target variables (and set some other conventions while we're at it):