I don't think that's what the other commenter suggested. The point is that TypeScript should disallow (or at least make harder) to write code which is hard to optimize by the VM - e.g. allowing function parameters to be of multiple types.

But TS has a design constraint to be essentially a superset of JavaScript so it would be difficult to realize this goal.

I had the impression, my code gets less polymorphic when I use TypeScript.

If only.

This is polymorphic because union types are polymorphic.

    let stringProcessor = (foo: string | number): string => {
      //do stuff with foo
      return "string" + foo
    }

It's super easy to make non-optimized arrays and objects this way.

    type MyFoo = string | number //somewhere in the codebase

    //you will get zero hints that this is a polymorphic function
    let formatFoos = (foos: MyFoo[]) => foos.map((foo) => `${foo} deoptimized`))
    

Any use of optional object properties also immediately leads to polymorphism too. I doubt you can find ANY significant TS codebase where this isn't used pervasively.

    interface Foo {
      foo: MyFoo  //polymorphic
      bar: string
      baz?: number //this is polymorphic too
    }

    let doStuff = (obj: Foo): string {
      //do stuff with obj
      return "string"
    }
    doStuff({bar: "abc"})
    doStuff({bar: "abc", baz: 123}) //we're now polymorphic

Even if we remove the `?`, it can still be polymorphic because the TS compiler doesn't reorder object properties when compiling.

    interface Foo {
      bar: string //all basic types, so we're good?
      baz: number //no more optional, so we're fine right?
    }

    let doStuff = (obj: Foo): string {
      //do stuff with obj
      return "string"
    }
    doStuff({baz: 123, bar: "abc"})
    doStuff({bar: "abc", baz: 123}) //we changed order, so now we're now polymorphic

I'm very surprised the property ordering would matter. Seems like the JS engine itself could easily fix that, no? Silently re-order the properties to fit its own optimization

Do you have a source for the above info? (both because I'm a little skeptical of some parts of it, but also because I'd love to learn more about this topic and I've had trouble finding concrete info in the past)

JS specifies that the order keys are added makes a difference. For this reason, entering them in two different ways is a fundamentally different, non-interchangeable object type.

You could preserve that information and still have the same native struct, since it only becomes relevant when iterating the keys

This seems like a moving target though, and I still don’t think the typescript compiler should be responsible for it. I think a linter could make sense though for obviously bad cases.

A linter can't tell if it's polymorphic -- only a compiler which is actually analyzing the types.