A big caveat looks to be that paid plan pricing is not disclosed. So likely geared towards enterprise customers.

Hi - I have been using this in production for a few months now, and haven’t experienced significant issues with debugging or troubleshooting.

It also helps that the library is type-safe - if we are overriding a function, we must comply with the signature of the original function for TS to pass.

Wrt. run time errors, the use of proxy does not interfere with good stack traces, if that is what you are worried about.

If we take the example in this gist where an overriden function throws an exception, we can see that the stack trace clearly shows the file (which overrides the hello function) where the exception is originating from.

In effect, the DX is not much different if you use any other mechanism for making some feature runtime configurable. In comparision to most traditional IoC/DI utilities I find the DX to actually be superior:

• Unlike a lot of other IoC solutions whose APIs are cloned/inspired from similar Java/C# libraries, you don’t need to wrap things in classes to participate in the DI system
• Also, that a function is overridable is transparent from consumer side - they just call a function that they import without needing any @Inject/@Provide boilerplate. This is great if you are writing a library or a small utility and don’t want to enforce usage of a specific DI/IoC library for your consumers.

What we don’t have (and likely will never) is support for things like request scoped DI or hierarchy of IoC containers. In mostly-functional TS code I have seldom missed those patterns.

Yes, that mode works pretty well. In my case I don’t really own the types (they come from a third party source) so being able to to auto generate validators from them is very convenient.

I use it in the code generator mode (https://typia.io/docs/setup/#generation) that doesn’t require the tsc plugin integration and works well with other build tools (in my case esbuild) and arbitrary testing/code-coverage libraries.

Lounge looks pretty cool

Build times in nodejs are not so great in even medium size projects if you make heavy usage of advanced typescript features - either yourself or through libraries like zod. So if something makes the nodejs runtime faster, it could potentially make ts compiler faster too - for which I’d be very grateful.

Tyson is nice - esp. if you are already using TS/JS.

https://github.com/jetpack-io/tyson

I like it. The docs are a bit scattered and I haven’t switched to it completely, but it has proven to be very handy for some scenarios where I scrape some content from external sources and pull them into a local sqlite as a long term structured archive.

I don’t use it right now, but two years ago I helped a team incrementally adopt Kotlin in a ten year old java/spring/mybatis codebase. We didn’t have any android experience and in the initial few months mostly used kotlin as a better java, avoiding features that would prevent us from switching back to java if needed.

But it worked pretty well - we didn’t face much resistence from people experienced with java because they could still continue to benefit from their jvm familiarity, and the language was approachable to new folks who joined us. It also helped that we could just copy paste java code into a .kt file and intellij would convert it to kotlin.

We didn’t venture into kotlin’s js/native targets but for jvm it worked out great for us.

I also have been using httpie for a few years - it is really great.

Recently I have started using nushell which has a similar module builtin: https://www.nushell.sh/commands/docs/http_get.html Combined with rest of the nicities in nushell its a pretty good cli experience.