41–49 of 49 posts
Earlier quoted context omitted.
TS language server will do that for you as go along
Wouldn't that defeat the point of what static typing affords you? Before you "go along"?
I wish enum was never part of TypeScript. It’s this one odd thing unlike the rest. Am I forgetting any or is it the only feature that actually generates code rather than just being extra annotation?
Strong disagree. enums + unions = ADTs. Without enums you have to use either string or number. The problem with using strings is that nothing else uses strings (like say, your database), so you have to have this interminable roundtrip conversion between strings and integers. JS programmers are in a bit of a bubble where using strings as enums is socially acceptable, if a C programmer saw this code typedef struct { co…
Pointing to a lower level language with a different use case doesn't justify int enums to me.
I haven't used it as I haven't had a need for it.
Earlier quoted context omitted.
Strong disagree. enums + unions = ADTs. Without enums you have to use either string or number. The problem with using strings is that nothing else uses strings (like say, your database), so you have to have this interminable roundtrip conversion between strings and integers. JS programmers are in a bit of a bubble where using strings as enums is socially acceptable, if a C programmer saw this code typedef struct { co…
I think string enums are actually totally okay considering they're interned and basically just pointers at the VM level, and then when you're debugging you don't need to figure out what the hell 0x72838ABC is. Pointing to a lower level language with a different use case doesn't justify int enums to me.
I wish enum was never part of TypeScript. It’s this one odd thing unlike the rest. Am I forgetting any or is it the only feature that actually generates code rather than just being extra annotation?
Namespaces do as well, but I think it's just those two.
Earlier quoted context omitted.
I mean I have not seen anything to suggest that angle brackets are "legacy or discouraged"
They're discouraged because they conflict with JSX. For instance, in the eslint documentation: > Most codebases will want to enforce not using angle-bracket style because it conflicts with JSX syntax, and is confusing when paired with generic syntax. https://typescript-eslint.io/rules/consistent-type-assertion...
(Or at least, they can't use this tool with it.)
Earlier quoted context omitted.
I mean I have not seen anything to suggest that angle brackets are "legacy or discouraged"
They're discouraged because they conflict with JSX. For instance, in the eslint documentation: > Most codebases will want to enforce not using angle-bracket style because it conflicts with JSX syntax, and is confusing when paired with generic syntax. https://typescript-eslint.io/rules/consistent-type-assertion...
Doesn't the new node feature to strip types handle this already? https://nodejs.org/en/learn/typescript/run-natively I haven't used it as I haven't had a need for it.
Node uses swc to do this. The swc implementation of blank-spacing (implemented here https://github.com/swc-project/swc/pull/9144) was inspired by the author of ts-blank-space here: https://gist.github.com/acutmore/27444a9dbfa515a10b25f0d4707.... It has just taken a little longer to release the original implementation.