ESNext target about typebox HOT 3 CLOSED

@CraigMacomber Hi!

I believe setting the module to ESNext was a good choice, but when that was done "target" was changed as well, which I think should be avoided. The TypeScript documentation on the subject...

Hey, thanks for spotting this, and I agree! There were many updates done to prepare TypeBox for dual publishing CJS/ESM on the 0.32.x PR, and it appears the the ESNext target for ESM was an oversight. Would be keen to fix the target to ES2020 (inline with the current CJS target).

In accordance with contribution guidelines in the readme I'm filing this as an issue and not a PR, but if you would like a PR making these changes I can provide one.

If you would like to submit a PR to help fix this up, that would be really appreciated :)

Many thanks!
S

from typebox.

@CraigMacomber Hi,

Have gone ahead and fixed this up and published a revision on 0.32.33 which is using the ES2020 target for ESM. Figured I'd resolve this as I'm trying to catch up on backlog of issues (currently working different 5 projects atm) :D

FluidFramework

I work on https://github.com/microsoft/FluidFramework, a happy user of TypeBox, and was working on our JS runtime compatibility story when I noticed TypeBox has its target set to ESNext

I actually meant to leave you a follow up comment the other week when you submitted this #865 (comment). I'm actually a fan of FluidFramework, and had noticed the project was using TB quite extensively. I'd paid attention to a couple of notes on the project around bundling size, and partially implemented isolated type imports (added on 0.32.x) as a possible means to help reduce bundling sizes (at a cost of having to import types individually). These may be worth checking out if you've not seen this before.

As an aside, I'm actually very open to receiving feedback from users who really push TypeBox far (which FluidFramework certainly does), this mostly to help identify any pain points when using the type system at scale (hundreds of types). All suggestions and feedback are taken onboard for future revisions, so if you are able to provide any insights, suggestions or general feedback it would really help the project along as well as give focus to new features.

Will close up this issue for now
All the best!
S

from typebox.

I actually meant to leave you a follow up comment the other week when you submitted this #865 (comment). I'm actually a fan of FluidFramework, and had noticed the project was using TB quite extensively. I'd paid attention to a couple of notes on the project around bundling size, and partially implemented isolated type imports (added on 0.32.x) as a possible means to help reduce bundling sizes (at a cost of having to import types individually). These may be worth checking out if you've not seen this before.

I had not seen that. We use most of the types, so I'm not sure if it will help our case, but its good to know its an option when I get time to look into our bundles size more.

As an aside, I'm actually very open to receiving feedback from users who really push TypeBox far (which FluidFramework certainly does), this mostly to help identify any pain points when using the type system at scale (hundreds of types). All suggestions and feedback are taken onboard for future revisions, so if you are able to provide any insights, suggestions or general feedback it would really help the project along as well as give focus to new features.

Once we are done getting our 2.0 release ready (hopefully this week), we should have time to work on things like bundle size. For now though I have filed #907 which I think is the main cause of unexpected bundling (other than some things on our end we need to clean up in our usage of TypeBox accidently pulling in the compiler when we shouldn't).

from typebox.