Hookyns/tst-reflect

Participation in the new version of the system

Hookyns opened this issue Β· 60 comments

Sign here who wants to participate in the alpha of the new major version. I will invite you to the private project when it is ready. πŸŽ‰

I am excited to see the new version of this library. I am willing to participate in the alpha of the new major version.

Hi, I want to investigate the potential of this library and would be happy to participate

Sign me up. I've been testing doing recursive model hydration with data from the Jira API. So far it looks very promising with the exclusion of one bug with getCtor but that looks like its been flagged as fixed in v1. I'd be happy to run the alpha through my use case.

nduc commented

Looking to see if I can leverage this for my Remix project. There's an issue with transmitting the class from backend to the front end via the useLoaderData(). I'm hoping to leverage this to send the meta data along so when it gets to the other side the class/object can be reconstructed.

I would like to be able to help with the alpha version. I was looking to use this package for generic classes which does not seem to be possible in the current version but will be in the new version (#30). My use case being to help create documentation from the actual source code to produce 'live' docs rather than manually documenting things.

i would to be able to use alpha on this

Hi guys, TY for your interest! πŸŽ‰

I'm late with the alpha, working hard on it. 🏭
I've invented new and better callsites (new way how to pass generic type arguments through project) so I'm rewriting some base stuff which results in not working project. I expect it to be ready by the end of next week.

I've already prepared website and documentation (first basic version).

Project will remain private for a while, I'll invite you into the organization and send you link to discord server, so you can get proper support and I can get some feedback I hope. πŸ™‚

caass commented

Hi! I'd love to participate in the alpha :)

Late (again), but it will be this week. πŸŽ‰

I'm stucked on one strange issue caused by strange conditions. I'm finally able to reproduce it. Now I have to fix it.

nduc commented

I was just looking at another repo for something else and it has a link to moddle. It might be of use to this project or someone else looking to reconstruct JSON to object. In my case I needed a way to convert an object to JSON and send it across the wire. Then reconstruct the object once it arrives on the client side.
BTW, I appreciate the hard work you're putting into your project!

I'm willing to participate

I've granted you access to the organization and mentioned you in an issue.

@Hookyns Please add me to the alpha!

Great project, thanks for your work @Hookyns! I'd love to join the alpha, too! :)

First of all thx for your awesome work! You saved me hours of work! I would like to join the alpha too!

Hi, I'd love to participate in the alpha!

Hey! I'd also like to join the alpha :)

Count me in!

nmnsnv commented

Hi!
I would love to join and check the alpha!

tutok commented

Hi, I really like what you are doing, looking for a similar solution for a long time, may I join too?

Hi, I'm interested in participating as well if it's not too late!

I was just looking at another repo for something else and it has a link to moddle. It might be of use to this project or someone else looking to reconstruct JSON to object. In my case I needed a way to convert an object to JSON and send it across the wire. Then reconstruct the object once it arrives on the client side. BTW, I appreciate the hard work you're putting into your project!

@nduc For that purpose, you may be interested in @badcafe/jsonizer : https://badcafe.github.io/jsonizer/#/README but you will have to call JSON.stringify() and JSON.parse() yourself.

I'm also working on its companion library @badcafe/asynchronizer but it is not yet released (planned for september 2023), which is an RPC lib that will let you call functions without worrying how to serialize parameters (and return values) in one side and how to deserialize them on the other side. Works with various channels : HTTP, WebSocket, Workers, nodejs clusters, etc with broadcast and multicast features, support for binary and streaming, and with nice binding to REST for the HTTP channel.

Hi, I'm interested in participating too if possible !

Is this project still happening? If so, I'm also interested.

I have extensive experience with reflection in PHP and C#, if that matters - I've written DI containers in both languages, and I also wrote one of the earliest annotation libraries for PHP. Where I'm stuck with TypeScript is there seems to be no good approach to dependency injection containers without reflection - I've spent years on-and-off trying to solve this with types, I've looked at every DI container with types, and it just doesn't seem feasible. I started tinkering with deepkit.io and I don't find their reflection approach at all useful.

So yeah, quite interested in testing this. :-)

Is this project still happening? If so, I'm also interested.

I have extensive experience with reflection in PHP and C#, if that matters - I've written DI containers in both languages, and I also wrote one of the earliest annotation libraries for PHP. Where I'm stuck with TypeScript is there seems to be no good approach to dependency injection containers without reflection - I've spent years on-and-off trying to solve this with types, I've looked at every DI container with types, and it just doesn't seem feasible. I started tinkering with deepkit.io and I don't find their reflection approach at all useful.

So yeah, quite interested in testing this. :-)

Sure! πŸ™‚

DI was the main reason why I started to work on this.
Here is my implementation of DI based on this project; quite outdated, it's just prototype, because this become the main project I want to finish first to build a lot of other things that need reflection.

Yeah, a DI container is the main reason I want reflection too. My ideas about a DI container is quite different from the "main stream" - quite a lot of non-features. I wrote at least 5 DI containers before settling on this. πŸ˜…

Sign me up

First prototype version of the new Typegen is out. πŸŽ‰
It works with SWC, esbuild and tsc without any transformations as expected. πŸ™‚

Information for participants is in the private repository.

It works with SWC, esbuild and tsc without any transformations as expected. πŸ™‚

🀩

how did you pull that off?? will be testing today. 😁

vjpr commented

Sign me up please!

I am also very interested πŸ‘€

how did you pull that off??

As we discussed earlier, Typegen is completely standalone tool which just take .ts files as input and generate static metadata library (I call it a typelib) as output; it's not part of the build process.

It's based on alpha's transformer. I just had to create the tool and rewrite some parts, it took just about 4 weeks of work and I'm a week behind with the prototype against expectations. 🀷

It's rly just a prototype. It only generate the typelib which you can use statically (Metadata.getTypes() and Metadata.getModules()). It's not possible to use the getType<SomeType>() yet. To allow usage of getType it will require a transformer as part of the build process, but it will be super simple transformer and it can be written for every build tool (esbuild, swc, tsc); it does not require TypeChecker (well TypeChecker will give you better results for inferred types so for SWC and esbuild there is not going to be full support of inferrence).

I need at least another month to get it into alpha phase.

well TypeChecker will give you better results for inferred types so for SWC and esbuild there is not going to be full support of inferrence

oh, okay, I thought you were trying to say you had come up with a solution.

so it's still going to be a limited version for SWC and ESBuild.

I'm still not sure if I think this is a good idea. I mean, imagine you ship something like a DI container or router that depends on this runtime, and you're showing cool examples like router.get("/path", (req, res) => ...) and it just doesn't work with popular bundlers. It's going to be weird. Every library will need caveats in the README to explain why the examples don't actually work with the popular bundlers - hardly anyone uses tsc.

and I understand why it's the best we can do.

but I still wonder if maybe it would be possible to integrate the official TS compiler into something like Vite... I guess if all of these tools are designed to work file-by-file, it's just not going to be possible? man, that's so frustrating. πŸ˜”

but I still wonder if maybe it would be possible to integrate the official TS compiler into something like Vite..

I think I have a possible solution for this too but I don't know what the performance will be. It may be even worse than switching to plain old tsc. But it's not a priority for me. I think that the planned supported features (for swc and esbuild) will be sufficient for about 50 % of use-cases which is still infinitely more than what's possible now. πŸ™‚ And you can still say that users have to enable strict mode (noImplicitAny to be specific), then it will work without any issues.

But it will have a solution in the future thanks to Donny's STC.

EDIT:
And I still don't see any issues with the DI. I always have to specify type to tell the system what type I want.

class SomeService {
    constructor(logger: ILogger, router: Router, somethingElse: SomethingElse) {}
    orMethodInjection(something: ISomething) {}
}

with registration like (super simple & naive implementation):

import { Metadata } from "./metadata.typelib";

class ServiceCollection {
    addSingleton(serviceType: Type, serviceImplementation: Type): void {}
    addTransient(serviceType: Type, serviceImplementation: Type): void {}
}

const sc = new ServiceCollection();
const serviceImplementations = Metadata.getTypes().filter(t => t.isClass() && !t.isAbstract() && t.name.endsWith("Service"));

for (let implementation of serviceImplementations) {
    sc.addTransient(implementation.implements.find(i => i.name.endsWith("Service")) , implementation);
}

There is no need to infer anything.

Here is a preview with esbuild, using the new Typegen and esbuild plugin.

Typegen is still a prototype (pre-alpha version) and the esbuild plugin is just a proof of concept, but I progress quickly.

Hi! Amazing job! I would love to give a try to the alpha version :)

Hello, I'm developer of typia, and wanna see how tst-reflect supports SWC/EsBuild

Great work πŸ™Œ I also want to join the alpha channelπŸ‘€

I'd like to participate =)

Hi, I'm interested in participating.

Please, I would like to test. πŸ˜„

Please, I want it too

Hi, I too have a very burning interest in such a thing

Hey, thanks a lot for this project!

Sign me up for the alpha too please, if you need contributors I'm willing to contribute too πŸ˜„

Hi @Hookyns I would be interested to participate and contribute.
Besides seems like you have a few group of brains interested some very good can come up if we all collaborate.

I'm the author of https://mion.io/

Good Job πŸš€β­οΈ

Hello guys,

I'll make the repo public soon.
Packages are on npm so you can test it. Keep in mind that it's still alpha version. It still doesn't support everything. I'm still working on Rust implementation of simple semantic analyser so functionality of getType<T>() is still limited.

You can visit rttist.org and docs.
It is still work-in-progress, but base instructions (and esbuild plugin) should work.

Post your feedback.

Here is the latest demo.

PS: I will greatly appreciate a PR to improve the docs!

Can I try out the alpha version?

Sign me up!

Would you please include me? Thanks!

Hi, can you please invite me?

Can I also join in? Thank you!

@Hookyns, count me in pleaseπŸ‘

Looking forward to checking out the new version πŸ”₯