You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently use @babel/runtime for helper functions used in transformer.
Should we publish our own @oxc-project/runtime NPM package and use that instead?
Initially, it could just re-export from @babel/runtime, but I can see various advantages of having our own package:
@babel/runtime may be updated and break our transforms at any time. We can lock the version of @babel/runtime used in @oxc-project/runtime to prevent that.
We have decided to diverge from Babel where we can produce better output, or need to do things differently because Rust. We may want to alter some of the helpers too.
We only use a fraction of the helpers because we're only supporting transform down to ES6. Our package can be much smaller than @babel/runtime.
It's just weird to tell users to install @babel/runtime as a dependency in their project to use Oxc.
The text was updated successfully, but these errors were encountered:
We currently use @babel/runtime for helper functions used in transformer.
Should we publish our own
@oxc-project/runtime
NPM package and use that instead?Initially, it could just re-export from
@babel/runtime
, but I can see various advantages of having our own package:@babel/runtime
may be updated and break our transforms at any time. We can lock the version of@babel/runtime
used in@oxc-project/runtime
to prevent that.@babel/runtime
.@babel/runtime
as a dependency in their project to use Oxc.The text was updated successfully, but these errors were encountered: