Our great sponsors
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
typescript-eslint
:sparkles: Monorepo for all the tooling which enables ESLint to support TypeScript
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
TypeScript-Call-Graph
CLI to generate an interactive graph of functions and calls from your TypeScript files
-
proposal-record-tuple
ECMAScript proposal for the Record and Tuple value types. | Stage 2: it will change!
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
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
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
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
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
- 5 Alternatives to Redux for React State Management
- Automating Data Collection with Apify: From Script to Deployment
- A list of SaaS, PaaS and IaaS offerings that have free tiers of interest to devops and infradev
- What will happen to the full-stack framework in the future?
- Dubbl3bee airdrop - Thirdweb smart contract security vulnerability mitigation