
Not Sucking at TypeScript: 3 Tips - thoughtspile
http://thoughtspile.github.io/2018/09/22/typescript-unsuck-guide/
======
Alexendoo
I would recommend avoiding adding your own global types if you can avoid it,
for example TypeScript has a full type definition for Array.prototype.find
[1]. You can enable it without changing the target and breaking things by
adding es2015 to lib in your tsconfig compilerOptions

[1]
[https://github.com/Microsoft/TypeScript/blob/5fb39769ada9ff7...](https://github.com/Microsoft/TypeScript/blob/5fb39769ada9ff72d905c62069aab136c93f38a8/lib/lib.es2015.core.d.ts#L22-L32)

~~~
thoughtspile
Thanks, I reckoned there was a way to get it done but never found one! Can you
also enable individual features, not the whole pack?

------
jeremychone
I would add 1) Starts with `strict: true` 2) Favor interface over class 3)
Functional first, OO as needed 4) Avoid Java way of coding, DI, Class for
everything.

~~~
thoughtspile
Nice ones! My first TS project was with a C# guy, so we had some virtual
classes, no good) Anyways, the TS community itself does not seem to enforce
OOP stuff too much — Angular / mobx do.

On the other hand, I don't know why the DI stuff never caught on in he js
world — it should be good for testablity (better than build-time magic at
least)?

~~~
jeremychone
Honestly, DI is really a thing of the OO-Obsessed world when everything has to
be a class and instantiated.

In the JS/TS world, we mostly use Interface/Type to describe constraints, and
most of the module export function or group of methods in a const (namespace,
module,...) but the caller does not have to know if it is a class or just a
object with some methods, and does not do a "new ..." or @inject... anymore.
Much simpler, much more intent driven, and you can remove a lot of boilerplate
code (which DI still is)

Now, one of the value of DI is for testing, and one way to accomplish module
compartmentalization, is with module-alias. It does not the granularity that
DI needs, but I would argue that if more is needed, it perhaps because the
testing and mocking got a little too out of hands. In our experience, thanks
to Kubernetes, we try to mock less, and have our test running mostly with real
services.

