typescript-is
typescript-eslint
typescript-is | typescript-eslint | |
---|---|---|
9 | 123 | |
951 | 14,612 | |
- | 0.9% | |
4.2 | 9.9 | |
10 months ago | 3 days ago | |
TypeScript | TypeScript | |
MIT License | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
typescript-is
- Good bye "typescript-is" (ancestor of "typia", 20,000x faster validator)
-
Typing for JSON Payloads
I'll throw https://github.com/woutervh-/typescript-is in the mix as well.
-
Handling json input in an express app
I'm a fan of typescript-is. Provides both compile time and run time validations
-
What can I *use* Rust for?
For what it's worth, thanks to TypeScript transformers (a feature baked into the compiler), one can create a transformer library that verifies an object is valid for any TypeScript type and conveys that information to the typechecker. And indeed, it's already been made. It allows to parse unknown into a given T. This is nice, because one can generate a JSON schema out of a TS type, for other languages/codebases to integrate safely.
-
Do you use code generators? If so, which ones?
But to make it worth the comment, I’ll point people to typescript-is which uses transformations at compile-time to generate run-time type checking code.
-
TypeScript runtime type-checking - designed for simple use, through to enforcing API payload schema
Then there's also typescript-is, which is pretty neat because it converts actual compile-time type definitions to runtime type checks, so it doesn't require changing the type definitions.
-
JSON Schema === Runtime Type System for TypeScript
typescript-is. This uses a compile-time transformer to generate code for type-checking. You'll need to use ttypescript instead of typescript to compile your code (I recommend setting this up with ts-patch). It won't work if your build pipeline is actually using something like esbuild or Babel to transpile TS->JS.
-
How an Anti-TypeScript “JavaScript developer” like me became a TypeScript fan
If you're not using a bunch of generics, check out typescript-is [1]. It takes little work to get it setup, but it generates run time type checks for you. I understand why typescript decided to not add this functionality to the core of the language, but it's starting to feel like the largest missing piece of typescript is a built-in way to generate run-time type-checks for user-defined types from just the type definition.
The happy medium we've found with that module is using the runtime type-check on anything "unsafe" to bless the result using typescript-is's equals functionality, but still allowing programmers to use casting with a comment justifying its necessity. For us our list of unsafe is results pulled from the db, anything parsed from JSON, and incoming request bodies (which can be a special case of parsing from JSON, but not always).
[1]: https://github.com/woutervh-/typescript-is
typescript-eslint
-
Mastering Type-Safe JSON Serialization in TypeScript
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".
-
Oxlint – written in Rust – 50-100 Times Faster than ESLint
> 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.
-
How to Do a TypeScript Conversion: an opinionated take on gradual conversions
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
- How do I add additional rules to my typescript-eslint settings?
- What's the best config for typescript-eslint?
- How do you add angular-eslint to your typescript-eslint config?
- What's the best typescript-eslint config?
-
The Best ESLint Rules for React Projects
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):
- Open source public fund experiment - One and a half years update
- Never touch those //ts-ignores
What are some alternatives?
runtypes - Runtime validation for static types
eslint-config-google - ESLint shareable config for the Google JavaScript style guide
class-transformer - Decorator-based transformation, serialization, and deserialization between objects and classes.
angular-eslint - :sparkles: Monorepo for all the tooling related to using ESLint with Angular
class-validator - Decorator-based property validation for classes.
ts-standard - Typescript style guide, linter, and formatter using StandardJS
typebox - Json Schema Type Builder with Static Type Resolution for TypeScript
zod - TypeScript-first schema validation with static type inference
ts-node - TypeScript execution and REPL for node.js
node-clinic - Clinic.js diagnoses your Node.js performance issues