
TypeScript: Template string types and mapped type 'as' clauses - Kinrany
https://github.com/microsoft/TypeScript/pull/40336
======
throwaway189262
Ok for real, is Typescript going to collapse one day from the complexity of
its type system?

Typescript's type system became Turing complete years ago, and hilariously,
someone linked that issue to the new types mentioned in this post :)
[https://github.com/microsoft/TypeScript/issues/14833](https://github.com/microsoft/TypeScript/issues/14833)

I've been using Typescript for years, and I still like it. But I'm starting to
get frustrated by the sheer amount of "stuff" they keep adding to the type
system. My coworkers are too. They don't want to spend weeks reading about
"advanced types", just want TS to be a nice wrapper around JS.

Typescript doesn't have a standard library or a runtime, so eventually can't
they just call it done? Just do occasional maintenance releases to keep up
with new JS features

~~~
gmac
On the one hand, yes, the code examples in that PR thread are kind of
terrifying.

On the other, the ability to map mechanically between type names would be
really useful, and is something I’ve previously wished for. It would, for
example, enormously simplify type generation for Zapatos[1], which currently
creates multiple long object mappings for this purpose, such as:

    
    
        export type SelectableForTable<T extends Table> = {
            accounts: accounts.Selectable;
            appleTransactions: appleTransactions.Selectable;
            authors: authors.Selectable;
            books: books.Selectable;
            emailAuthentication: emailAuthentication.Selectable;
            employees: employees.Selectable;
            identityTest: identityTest.Selectable;
            stores: stores.Selectable;
            tags: tags.Selectable;
            tableInOtherSchema: tableInOtherSchema.Selectable;
        }[T];
    

[1] [https://jawj.github.io/zapatos/](https://jawj.github.io/zapatos/)

~~~
Kinrany
Since you're generating types anyway, can't this be simplified to
`tableTypes[T]['Selectable']`?

~~~
gmac
Nice thought, thanks, but I don't think so.

The way things are set up, your `tableTypes[T]` would need to map table names
to namespaces, and this gives errors like "Cannot use namespace 'X' as a
type".

Would be pleased to be proved wrong, though. :)

------
chadlavi
I still really, really want RegExp types

~~~
reificator
Is the javascript regex literal or builtin RegExp type not sufficient for your
needs? What are they missing?

[https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/RegExp)

~~~
tengbretson
I think the op is asking for actual type refinement by a regex condition.

~~~
chadlavi
especially as a library maintainer, I would really love to be able to say, for
example, "you have to pass an email address to this prop" or "you have to pass
a US phone number"

~~~
reificator
So you're the one I should blame whenever some regex fails to validate my
perfectly standards compliant email address!

I get very frustrated when I sign up for storefronts using an email with a
`.dev` address and some wanker decides that I shouldn't be allowed to give
them money because my email address doesn't end in `@gmail.com`.

Stop this. Regex is not the right tool for this job. If you're going to use
the regex hammer at least use the full standards compliant one shown here:
[https://stackoverflow.com/a/201378](https://stackoverflow.com/a/201378)

> _The problem with regular expressions is that telling someone that their
> perfectly valid e-mail address is invalid (a false positive) because your
> regular expression can 't handle it is just rude and impolite from the
> user's perspective. A state engine for the purpose can both validate and
> even correct e-mail addresses that would otherwise be considered invalid as
> it disassembles the e-mail address according to each RFC._

~~~
spicybright
Or if you're even too lazy for that, just match `.+@.+` and handle errors
properly if sending an email fails (which you'll obviously have to handle
anyways as a valid email address might not be in service)

