Thoughts about import-esm and import-deno

[gustavo-shigueo]

As I explained here, I don't love the import-esm feature, especially now that it is causing issues with @eythaann attempting to add support for Deno, which expects import statements to have a .ts extension.

Doing this through another feature would mean we have two incompatible features, making our CI test for --all-features quite awkward to say the least.

With that in mind, I suggest we drop the import-esm feature entirely (or at least flag it as deprecated and emit a warning for those using it to show our intent to remove it) and add a new attribute that allows the user to control what file extension our import statments use.

I'd like to hear some thoughts about this though, what do you think @NyxCode?

It'd also be nice to hear what the people who asked for import-esm think as well, though I think it's unlikely they'd answer, given that it's been 2 years, still, I'll tag them here in the off chance they see this

cc: @carlocorradini - original issue author
cc: @h7kanna - hearted the original issue
cc: @grindarius - hearted the original issue

[eythaann]

The library already uses ENV variables to configure the output dir of types, we can use another env var to toggle the import way to some enum like TS_RS_IMPORT_EXTENSION = none | ts | js with none as default

[eythaann]

And as backguard compatibility if import-esm is enabled the default of the env will be js instead of none

[gustavo-shigueo]

This is an interesting idea,, I hadn't even thought of using env variables to do this. A benefit is that it would be very easy to transition, just replace the features = ["import-esm"] in Cargo.toml with an environment variable (which could be done with a .cargo/config.toml file), which is much easier than my idea of "add an attribute to every type"

[carlocorradini]

Hey, I like using the env variable to configure the extension.
Having too many features increases overall complexity.

In addition, I would like to point out that this package needs a way to export the types within build.rs (I am not sure if this is possible). With the latter, we could have much more control using a simple, clean builder pattern.

[gustavo-shigueo]

Hey, I like using the env variable to configure the extension.
Having too many features increases overall complexity.

Hey, thanks for replying! Yeah, the idea of having this be a feature flag was one of @NyxCode's original concerns with our implementation, but at the time we didn't see an alternative - that was before we started using env variables

In addition, I would like to point out that this package needs a way to export the types within build.rs (I am not sure if this is possible). > With the latter, we could have much more control using a simple, clean builder pattern.

For this to be possible we'd need to have type information (more specifically trait impls) at build time, which I don't think we have, unless build.rs has some kind of special access to type information.