3 ms·

The case he describes seems like a really bad example. All of that code could be rewritten to use properly composed functions - a library, for sure, but the com

by 9dev 3y ago

The case he describes seems like a really bad example. All of that code could be rewritten to use properly composed functions - a library, for sure, but the complaint isn’t valid. That’s like writing procedural PHP with the database connection defined inline everywhere you use it. There is no need to do so if you can import modules! Are there any actual cases where a macro system in TypeScript would be useful?

mirekrusin 3y ago
I think it could be useful for cases where codegen is used - creating ts file that operates on a list of files in directory, autogen for client/protocol based on some schema/declaration.
jakear 3y ago
TS allows terms to depend on terms (normal JS functions), types to depend on terms (typeof operator, polymorphism, etc.), and types to depend on types (mapped types, inferred types, etc.), but not terms to depend on types. Macros could help there, the real world use case would be things like the classic: JSON.parse<{someField: string}>(...), in which a macro might allow the term to depend on the type (i.e. throw if the line data doesn't deserialize into the type). This of course, goes against the "prime directive" of typescript and would never see the light of day in the core compiler, which is probably a good thing. But for a hobby project it'd be interesting. In large scale TS applications of my experience, there's always several places where you're writing out long terms exactly corresponding to types in some mechanical way, but there's no real infrastructure to help you there so it's just a manual process.
- 9dev 3y ago
  > In large scale TS applications of my experience, there's always several places where you're writing out long terms exactly corresponding to types in some mechanical way, but there's no real infrastructure to help you there so it's just a manual process. I’ve been at this point several times, and for most of the time, the solution was to either use the satisfies operator or remove explicit type declarations in favour of what TS infers on its own, then refactoring the code. This resulted in a leaner, more elegant, and most importantly correctly typed code base. YMMV of course, and sometimes this just isn’t possible, but I believe macros to be way too dangerous for that fringe use case or hobby project - inexperienced developers would jump to introduce them everywhere immediately, guaranteed.
- oreille 3y ago
  Although I have no idea how they managed to do so, someone actually made the parse<SomeType>(someVariable), possible in native typescript: https://deepkit.io/library/type https://deepkit.io/library/type
  - jakear 3y ago
    Not native typescript, they hack into the compiler. Their minimal `deserialize` example is also 250kB (!!!!!!) minified. Not really an option. https://docs.deepkit.io/english/runtime-types.html#runtime-types-installation https://docs.deepkit.io/english/runtime-types.html#runtime-t...
paulddraper 3y ago
> Are there any actual cases where a macro system in TypeScript would be useful? A lot of use cases involving decorators today (which are really rough for tree shaking). Writing type-safe SQL queries. Using JSONSchema.

by 9dev 3y ago

mirekrusin 3y ago

I think it could be useful for cases where codegen is used - creating ts file that operates on a list of files in directory, autogen for client/protocol based on some schema/declaration.

jakear 3y ago

TS allows terms to depend on terms (normal JS functions), types to depend on terms (typeof operator, polymorphism, etc.), and types to depend on types (mapped types, inferred types, etc.), but not terms to depend on types. Macros could help there, the real world use case would be things like the classic: JSON.parse<{someField: string}>(...), in which a macro might allow the term to depend on the type (i.e. throw if the line data doesn't deserialize into the type). This of course, goes against the "prime directive" of typescript and would never see the light of day in the core compiler, which is probably a good thing. But for a hobby project it'd be interesting. In large scale TS applications of my experience, there's always several places where you're writing out long terms exactly corresponding to types in some mechanical way, but there's no real infrastructure to help you there so it's just a manual process.

9dev 3y ago
> In large scale TS applications of my experience, there's always several places where you're writing out long terms exactly corresponding to types in some mechanical way, but there's no real infrastructure to help you there so it's just a manual process. I’ve been at this point several times, and for most of the time, the solution was to either use the satisfies operator or remove explicit type declarations in favour of what TS infers on its own, then refactoring the code. This resulted in a leaner, more elegant, and most importantly correctly typed code base. YMMV of course, and sometimes this just isn’t possible, but I believe macros to be way too dangerous for that fringe use case or hobby project - inexperienced developers would jump to introduce them everywhere immediately, guaranteed.
oreille 3y ago
Although I have no idea how they managed to do so, someone actually made the parse<SomeType>(someVariable), possible in native typescript: https://deepkit.io/library/type https://deepkit.io/library/type
- jakear 3y ago
  Not native typescript, they hack into the compiler. Their minimal `deserialize` example is also 250kB (!!!!!!) minified. Not really an option. https://docs.deepkit.io/english/runtime-types.html#runtime-types-installation https://docs.deepkit.io/english/runtime-types.html#runtime-t...

paulddraper 3y ago

> Are there any actual cases where a macro system in TypeScript would be useful? A lot of use cases involving decorators today (which are really rough for tree shaking). Writing type-safe SQL queries. Using JSONSchema.