Configure tsconfig.json to only load @types/node for Node programs

[sebinsua]

Configure tsconfig.json to only load @types/node for Node programs, and not to pollute code which runs on the browser with the following types.

Issue brought up in #8 (comment) and #1 (comment) (although the latter is more from ESLint's perspective).

I suspect 'solution-style tsconfig.json' are the right approach but these are very new so might lack support.

[sebinsua]

Might make sense to do this once there is some code btw. At that point any issues will become clear...!

[sanjayk]

For the core framework, Do we want any traces of TS at all? Why not simply use JS?

[sebinsua]

@sanjayk It allows us to dogfood types and currently many major projects have or are being rewritten in TypeScript. So it's mainstream now and the DX is much better than it was 4 years ago.

There is another way of doing it though. You can also use JSDoc strings and run tsc against these.

However, that's not my preference because I only heard about it recently and it's presumably not how Microsoft expected TypeScript types to be written. I can see a benefit in that you wouldn't have to strip the types, but I'd like to see more successful projects that do this before picking it.

[sanjayk]

I understand the urge to "follow" everyone. Remember Coffee Script? Some big hitters behind it too.

I am not against TypeScript for Module writers, for core frameworks, I am still a purist because types in JS are unnatural (not to mention has zero runtime protection unlike strongly typed languages). For the core, at what point we believe that TS simply wins and ECMA becomes TS.

[sanjayk]

Things like this concern me.

https://www.typescriptlang.org/docs/handbook/generics.html

In languages like C# and Java, one of the main tools in the toolbox for creating reusable components is generics, that is, being able to create a component that can work over a variety of types rather than a single one. This allows users to consume these components and use their own types.

[sebinsua]

What about generics concern you?

[sanjayk]

It is not a natural JS construct and the burden to learn a "new language" is quite large. In essence, at some point, JS will look a lot like C#. I am unsure at this point we need make that call on behalf of the company, even if it is being endorsed by some very well known people. I am not sure learning 2 languages is better DX or that most engineers are proficient with basic JS.

[sebinsua]

You are right that they aren't JS constructs but I wouldn't call it a huge burden on beginners. In fact, it does make it easier to refactor code, understand how APIs work, and avoid runtime errors.

Will JavaScript look like C#? Code like this still looks like JavaScript to me.

[sanjayk]

I am probably not doing a good job explaining. I am sure well written code by well meaning engineers will look great. Betting on TS for a core piece of the Framework gets us what? It is mostly for engineers that should know JS well enough.

For a generic Module builder, they can use the next amazing flavor of a language that can be transpiled to JS. Only a matter of time before other natural languages will do this (Think Kotlin/Scala etc. for the JVM)

[sebinsua]

My perspective is that we can make the code-base better by using TypeScript. Easier to understand, easier for others to contribute to, etc.

Does an excellent JavaScript engineer need TypeScript to help them refactoring some code? Generally not.

However, I've worked on JavaScript projects before with 100s of files, where refactoring caused lots of runtime errors that I had to painstakingly fix one-by-one. It is much easier to do this with a type-checker: you can often do what would have otherwise been extremely difficult refactors that might have taken a week or so or in just a day. Static typing is also a useful tool for power users.

[sanjayk]

I know I am in the minority BTW!

If the teams feels strongly, then, we make it a thing

[sebinsua]

@sanjayk I will not let anybody write code which looks like C# or Java. Trust me! 😆

(I like to write TypeScript code which is basically like simplistic JavaScript, to avoid complicated types and to try to only put types on function arguments and returns instead of interleaving them all over the place.)

[threepointone]

We don't load @types/node at all, closing this.

[NMinhNguyen]

We don't load @types/node at all, closing this.

That's incorrect. Most of the code in this repo is Node.js code (e.g. the CLI etc.) written in TypeScript, and it should be linted/type-checked accordingly.