-
This particular example is close to my heart: the definition files for things like JSON.parse() were written before the "unknown" type was introduced as an alternative to "any"
And because this "any" is coming from an external definition file, it can't be caught by tsc's --noImplicitAny nor eslint's no-explicit-any
Those two rules allow us to protect us from our own code, but not external definitions/libraries. Relevant GitHub issue here — https://github.com/microsoft/TypeScript/issues/26188
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
Here's an alternative to TypeScript that people who dislike type complexity but want better tooling, might find interesting: https://github.com/keyboardDrummer/typeless
Disclaimer: I'm the author
-
Looking at GitHub statistics, I would dare say TypeScript is pretty accepted: https://madnight.github.io/githut/#/pull_requests/2020/4
Out of all open pull requests on GitHub at the end of 2020, 18.8% were JavaScript and 6.7% were TypeScript.
For reference CoffeeScript was at 0.25%.
-
If you are working on the server side, ts-node has been a huge timesaver. It removes the extra step of compiling and lets you just run your script with `ts-node script.ts` or even `#!/usr/bin/env ts-node` at the top of your file works.
https://github.com/TypeStrong/ts-node
-
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
:sparkles: Monorepo for all the tooling which enables ESLint to support TypeScript
Looks like eslint is working on a new set of rules that would help with these currently-unprotected any cases: https://github.com/typescript-eslint/typescript-eslint/issue...
> Create a rule which uses type information to determine when you're inadvertently breaking type safety by using an any, potentially without knowing.
> Often libraries (or even the typescript defs themselves) can have weak(/lazy) types which return any. If you're not careful, you can inadvertently introduce anys within your codebase, leading to bugs that aren't caught by the compiler.
-
Doing runtime-typechecks really is a blessing, and it would be great if typescript would provide this as a language-feature. There are two more libraries I know which are great for that:
* Zod: https://github.com/colinhacks/zod
-
TypeScript-Call-Graph
CLI to generate an interactive graph of functions and calls from your TypeScript files
Mildly-related project I have: generate call graph for typescript files
https://github.com/whyboris/TypeScript-Call-Graph
The TypeScript language service is really neat -- you can use it to parse through .ts files so you can, for example, see which functions call which functions.
-
I like io-ts, but I've moved mostly to runtypes: https://github.com/pelotom/runtypes
-
proposal-record-tuple
ECMAScript proposal for the Record and Tuple value types. | Stage 2: it will change!
There's a Stage 2 proposal before TC-39 to add immutable Record and Tuple types [1] which would be structurally compared and perfect for complex Map keys.
It's also easy enough to find or write quick simple Map wrappers that use a hash function on an object as keys when provided (either piggy-backing on the existing Object.prototype.valueOf, which always exists on every object and easily falls back to the reference-based current behavior, and expecting classes to have custom overrides for that, or using a Symbol named function of their own to avoid polluting own-property-keys/name clashes with other libraries).
[1] https://github.com/tc39/proposal-record-tuple
Related posts
-
Hacktoberfest for Low or No-Code Professionals: Contribute to OSS Projects
-
Hacktoberfest 2024 with Ghostfolio
-
Encapsulating the Past: How We Tamed a Legacy System with Timeless Software Engineering Principles
-
My Second Year as a Developer Advocate: A Journey Through Different Conferences
-
Decentralized category with challenges from OP Guild, Avalanche, Thirdweb, and Arcadia