Currently @oxc-project/runtime's version is synced with the transformer's version. This has some downsides:
- the user need to sync the version of
@oxc-project/runtime and oxc-transform
- the runtime helper is bundled multiple times when a user uses multiple libraries that used different versions of oxc to transform the code
By untangling these (i.e. having a separate version for @oxc-project/runtime), we can solve these downsides.
@oxc-project/runtime version will not be bumped frequently so it'd be easier to bump oxc-transform version (and Rolldown / tsdown version)
- Since
@oxc-project/runtime 1.1.x will be compatible with 1.0.x, a single 1.1.x can be bundled inside of multilpe versions.
That said, there's one problem with doing this. Bumping the required @oxc-project/runtime version in oxc-transform is technically a breaking change. I guess that is fine as that's the way tslib (TypeScript) handles. Babel handles this by inlining the missing newer helper functions if the installed helper package does not have them.
refs oxc-project/website#986
Currently
@oxc-project/runtime's version is synced with the transformer's version. This has some downsides:@oxc-project/runtimeandoxc-transformBy untangling these (i.e. having a separate version for
@oxc-project/runtime), we can solve these downsides.@oxc-project/runtimeversion will not be bumped frequently so it'd be easier to bumpoxc-transformversion (and Rolldown / tsdown version)@oxc-project/runtime1.1.x will be compatible with 1.0.x, a single 1.1.x can be bundled inside of multilpe versions.That said, there's one problem with doing this. Bumping the required
@oxc-project/runtimeversion inoxc-transformis technically a breaking change. I guess that is fine as that's the way tslib (TypeScript) handles. Babel handles this by inlining the missing newer helper functions if the installed helper package does not have them.refs oxc-project/website#986