Keep TypeDefinitions in Runtime Flag in tsconfig.json

[nxpatterns]

Suggestion

I would like to use TypeDefitions also as TypeGuards in Runtime, without using weird methods like:

  hasSameStringKeys<K extends string>(
    data: any,
    keys: K[]
  ): data is Record<K, string> {
    for (const key of keys) {
      if (typeof data[key] !== 'string') {
        return false;
      }
    }
    return true;
  }

Instead of that above, that would be enough: variable:TypeDef. Errors in the console are desired. Anybody can active it if they want to.

🔍 Search Terms

Already searched, nothing found, btw: I cannot imagine that someone else has already suggested that; I think nobody is so insane, and nobody wants to be insulted by wannabe experts.

✅ Viability Checklist

My suggestion meets these guidelines:

• [ + ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [ - ] This wouldn't change the runtime behavior of existing JavaScript code
• [ + ] This could be implemented without emitting different JS based on the types of the expressions
• [ - ] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• [ ? ] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

tsconfig.json → keepTypeDefsInRuntime = true

📃 Motivating Example

Short Explanation:

All breaking TypDefs are visible in the console.

Longer Explanation

With TypeScript, we have one of the most significant programming languages ​​on the planet; finally, a programming language that supports types at compile time and can be used in both the backend and the frontend.

And I guarantee you that sooner or later, a runtime type check will come. Now, who could do better than Microsoft for TypeScript? Either TS-Team is now starting to think about it, or it will be pushed out by another language that offers this feature out of the box.

At the latest, when you are dealing with many API suppliers, and they charge you dearly for every meeting, simply because API contract testing is a tedious, time-consuming opportunity, you will think about introducing Runtime TypeChecks. You would ask your suppliers to correct the error/warning messages in the console until they are type-safe.

A runtime type checking feature is an immense competitive advantage. Why not think about it now?

💻 Use Cases

Check if the application and the APIs are using the proper TypeDefs.

[MartinJohns]

Duplicate of #1573 and many others. Also explicitly mentioned as a non-goal in the Design Goals.

[nxpatterns]

Dear Martin, it was an 8-year-old post, time changes; if you want to be competitive, you have to reconsider it, maybe it is the right time now.

Principally: I would like to ask you and other fellows kindly, PLEASE, PLEASE, only positive and constructive comments. It should not look like StackOverflow here.

[MartinJohns]

It's not for me to reconsider, it's the position the TypeScript team holds and repeatedly mentions. Last time a few days ago in a similar issue: #49610

[nxpatterns]

but sorry, it has nothing to do with my suggestion; mine is about an optional tsconfig flag, --> optional <--

p.s. If it is not for you to reconsider: Would you please let the decision-makers comment? It would be very nice of you.

[MartinJohns]

Your suggestion requires type information to be emitted, as does the other issue, and this is explicitly rejected in the Viability Checklist and in the language design goals.

But I'm unsubscribing from the issue now, I mentioned the duplicate and that this is explicitly out of scope for TypeScript. 🤷 The same issue comes up every now and then. The TypeScript team will reject it once they're working.

[nxpatterns]

Sorry, Martin, please do not participate if you have nothing positive to share. You can save me and you and others' nerves. I want to have a positive discussion here and not be lectured by someone who only has negative things to say.

Better you delete your comments in order not to influence others negatively. After all, Microsoft must also be guided by customer requirements.

EDIT: On weekends nerds like me will read and comment on it, don't worry about that. Please give the idea a chance before you kill it.

[nxpatterns]

Microsoft employees are generally very well behaved, Daniel (TS Mgr) is also a lovely guy, and he is very hard working too; I met him several times.

Perhaps there is a reason why this is not taken into account if what Martin says is true? A rude no is not something I would have expected.

[RyanCavanaugh]

We aren't going to make a runtime type system. This comes up reasonably often and the arguments here have been reiterated many times, and we don't need to have an additional iteration here.

[fatcerberus]

Already searched, nothing found, btw: I cannot imagine that someone else has already suggested that; I think nobody is so insane, and nobody wants to be insulted by wannabe experts.

I'm just really confused by this because something like this has been suggested many times, and nothing insulting was said in this thread that I can see.

[nxpatterns]

Dear @RyanCavanaugh, Can you please tell us, curious people, why you don't want to implement it?

You don't have to change the JS runtime; you have to convert the TypeDefs into functions in runtime.

Even if it sounds absurd, it goes in the same direction: For example, there is no enum in JS, but in TS, it is converted so that JS treats it as if it were a real enum. You would then have to do something similar for TypeDefs.

If you don't do it, we have to do it and have to build weird constructs to ensure Type-safety in Runtime in case of complicated Types (APIs are not always in our control).

Please forgive me; I find this approach unreasonable. It looks like TS has reached its limit. Unfortunately, there is a lack of revolutionary thinking here sorry.

What a pity!

[nxpatterns]

Dear @fatcerberus, your comment is already an insult, there is a lack of sensitivity, and unfortunately, I have to make the same mistake because of you. Before you write, please consider whether this is absolutely necessary?

It is incredibly tiring to argue with people who, on principle, must always be right. I'm looking for the truth, and I'm happy when I'm wrong because then I've learned something new. Please think about it!

Kind greetings,..

[RyanCavanaugh]

This has been covered in many previous issues, which you can read. I am not going to spawn another instance to have that discussion again; it doesn't scale.

Your behavior of chewing out anyone who comments on your post is not acceptable behavior. Do not repeat this; this is an official warning.