Roadmap

[avin-kavish]

Hey @Hookyns, I'm using tst-reflect in a pretty serious open-source project. I'm looking to have a stable but beta release of it in 2-3 months. There are a few things I need on this end to support that. So I'm wondering what are your plans and commitment to this library?

Namely I need,

• ES Module support
• Generate and ship metadata in a npm package
• Current features to be stable

[Hookyns]

Hi @avin-kavish, glad to hear it, unfortunately idk if I can make it in 2-3 months.
Here is my milestone and I'd be happy if I can make it to that date.

I'm working on the new version with rewritten core, cuz this core has some issues in specific areas. I've split this lib into more packages, changed the configuration and a few things in the runtime package (eg. names of some classes Property -> PropertyInfo; some properties into methods and so on) to standardize the interface and make it stable. Workflow remains the same.

Current version is IMHO stable JUST for some specific use cases. Nobody has used this lib in a big project on complex types yet. The runtime has tests so the runtime is quite well covered but TypeScript allows a lot of stuff to do with the types and the transformer do not cover it all.

It is possible to update current runtime to match new interface from the new version, so it will break now, not later.
I can tweak current transformer and make it more stable, I mean to remove throws with debug info and in such cases just return Type.Unknown. It will always build the project, runtime will always work too, but type will be Unknown in such cases.
But if it works for you now, it is okay.

Regarding your points:

• ES Module support: ES Module support is not a problem. I just study how the nodenext option should work so I can implement it correctly.
• Generate and ship metadata in a npm package: What is the use case? Now the end application using reflection should generate types, even for an npm packages. Is it supposed to be some kind of optimization?
  Package built with current version can contain metadata and the package can work with them and also package can work with Types from end application.
• Current features to be stable: See the text above.

[Hookyns]

@avin-kavish I think I'm done. Test it with tst-reflect@0.8.0 and tst-reflect-transformer@0.10.1.

I tweaked the transformer a little so:

• some errors are just warning,
• throws replaced by warnings and Unknown type returns,
• some warnings contain file and location,
• targets, modules and module resolution should be fine,
• generic types are handled in a way I told, so Logger<Foo> is not equals to Logger<Bar>, but for bothtype.isGenericType() == true and type.genericTypeDefinition is the same "base" generic type.

import * as _ßr from "tst-reflect";
import {getType} from "tst-reflect";

_ßr.Type.store.set(11353, {k: 8, n: "T"});
_ßr.Type.store.set(11354, {
	k: 0,
	isg: true,
	n: "Logger",
	fn: "@@this/dev/quick-tests/index.ts:Logger#11354",
	args: [_ßr.Type.store.get(11353)],
	tp: [_ßr.Type.store.get(11353)]
});
_ßr.Type.store.set(11351, {k: 0, isg: false, n: "Foo", fn: "@@this/dev/quick-tests/index.ts:Foo#11351", args: []});
_ßr.Type.store.set(11359, {
	k: 0,
	isg: true,
	gtd: _ßr.Type.store.get(11354),
	n: "Logger",
	fn: "@@this/dev/quick-tests/index.ts:Logger#11359",
	args: [_ßr.Type.store.get(11351)],
	tp: [_ßr.Type.store.get(11353)]
});
_ßr.Type.store.set(11352, {k: 0, isg: false, n: "Bar", fn: "@@this/dev/quick-tests/index.ts:Bar#11352", args: []});
_ßr.Type.store.set(11360, {
	k: 0,
	isg: true,
	gtd: _ßr.Type.store.get(11354),
	n: "Logger",
	fn: "@@this/dev/quick-tests/index.ts:Logger#11360",
	args: [_ßr.Type.store.get(11352)],
	tp: [_ßr.Type.store.get(11353)]
});

console.log(_ßr.Type.store.get(11359).fullName);
console.log(_ßr.Type.store.get(11360).fullName);

This part is new:

{
	isg: true, // is generic
	gtd: _ßr.Type.store.get(11354) // generic type definition
}

[avin-kavish]

Works great!

[avin-kavish]

Is it supposed to be some kind of optimization?

yes. Typescript compiler is quite slow already (compared to transpilers like swc). I wouldn't want it to process my npm packages again and again. I'll just test the current implementation as is and let you know if further improvents are desirable.

Regarding complex types, I'm just happy if it fails silently and returns unknown. With dependency injection the expectation is that complex types are not used and it's just simple inherited classes and interfaces. Regarding debug info, I'm getting some red error messages that print "unable to find type, returning unknown." Couple of issues with this,

• it doesn't say where, and it's pretty hard to find where considering all the interlinked dependencies. So maybe it could show some hints like class name or property name etc.
• I think red error is too severe, in most cases it doesn't break the application so I think a yellow warning is better. I catch unknown types where ever it could actually be a problem to my logic.

One stability issue I ran into was duplicate type information with different fullName being produced for the same type (with different # numbers after the type name). That would be a blocker because it's not possible to compare the equality of types. Do you know about any such issue? I was using ts-node, could it be related to that? I don't have a reproduction now, but I'll get that if it happens again.

I don't think I'm in a rush to get your updated logic. I have all the features I need with the current version. So just with ES module support, it'd be good to go for me.

[Hookyns]

Okay, so I'll tweak the transformer a little. 🙂

There were an old fullName issue regarding to generic types. That has been fixed. I'll try to write some extra tests for this.

The # number is ID of the type generated by the TypeScript compiler itself. (negative numbers are generated by this lib in case the type has no ID) There should be no difference in IDs for the same type. Well, maybe it can be caused by type aliases. I'll write some tests.

[avin-kavish]

Found it!

interface Foo {}
interface Bar {}
interface Logger<T> {}

console.log(getType<Logger<Foo>>().fullName) // Logger#95
console.log(getType<Logger<Bar>>().fullName) // Logger#98

Maybe it's unpacking generics like c#, by creating two versions behind the scenes.

[Hookyns]

Yeah, that's what I thought.

It makes sense and I think I'll change the current behavior with Array, Promise etc. to keep the C#-like behavior. Cuz that's what TS seems to do too.
What do you think?

[Hookyns]

It will be necessary to add isGenericType() and getGenericTypeDefinition(): Type, which will allow you to compare that two generic types are created from the same generic type definition.

[avin-kavish]

yeah, something like that would work. Can you actually get the generic type? What about directly generating one Type for both, just with different type parameters?

[Hookyns]

I've just debugged those types...

getGenericTypeDefinition will be simple, cuz that's what TypeScript rly do. They handle generic types the same way the C# do.

TypeScript's type resolved from Logger<Foo> is rly an "instance" of the generic type. They call it TypeReference and this TypeReference type has target property which is the base generic type definition same for all the generic type references.

I'll keep this behavior, because it will be easier and it will keep the same logic as TS itself and C#.

[avin-kavish]

someType.is(Type.Unknown) always returns false. How do I check if a type is unknown?

[avin-kavish]

Looks like this release broke enums. type.getEnum()?.getValues() returns undefined.

[Hookyns]

What's the enum declaration? All my tests passed.

[avin-kavish]

It's very hard to reproduce. Only happening in that specific case.

[avin-kavish]

export enum Mode {
  development = 'development',
  production = 'production',
}

You can check this, but I couldn't reproduce it when using directly with getType<Mode>(). I'll get back to you with a reproduction.

[avin-kavish]

Okay so this issue also turned out to be caused by ts-node. Now I'm just using ttsc. It's less buggy.

[avin-kavish]

Ran into another case of import path being wrong

[Hookyns]

Is it project import, or package import?

[avin-kavish]

project import. It added ./xxx.js when it should have been ./yyy/zzz/xxx.js

[avin-kavish]

Got another case of the same type having two type ids, not even a generic this time.

[avin-kavish]

Is there a way for me to debug the inline types of my project when using ts-node?

[Hookyns]

I don't use ts-node so I don't know if you are able to debug it but it should work the same like with ttypescript.

As I write in CONTRIBUTING, you have to run it via node, directly, because that's what you can debug. cd to/project/folder && node node_modules/ttypescript/bin/tsc. You should be able to do the same with ts-node. You just have to find the ts-node binary, find the executed JS file and execute that JS file directly.

EDIT: You can always try ttypescript, just to debug it. It should behave the same.

[Hookyns]

BTW: I've tried several scenarios but I always get correct fullName. 😞

[avin-kavish]

I think #64 is related.