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
This might need RFC in the future, for now trying to describe the issue for the record.
Currently, SWC's rust packages (which are published in crates.io) do not follow semver. Instead, use the latest versions to ensure build passed. There were some rough edges but it worked mostly.
With plugins, this becomes more challenging. There are various cases the recommendation cannot be followed,
inter-pkg version conflict when reference / import swc_plugin and other packages in the plugin code itself
i.e swc_plugin's transitive swc_common does not match to the direct dep's swc_common version. User have to look into swc_plugin's version tree, then match it with its direct import.
This gets more complex if we want to ensure compatibility across different host runtimes, for example next-swc does not use latest swc always, which can result like vercel/next.js#38428 . Currently there's no way to make plugin to be compatible between @swc/core and next-swc if those 2 hosts are diverged.
In the end, we may need to introduce some sort of semver compliant to prevent these. It needs some thought around how. Probably we'll need to create single SDK-like entrypoint pkg which includes all of the transitive deps, can be feature-flag controlled in compile time and those pkg ensures semver - all of rust binary should import those package only, any direct import to trasnsitive dep won't gaurantee semver in that case.
Babel plugin or link to the feature description
No response
Additional context
No response
The text was updated successfully, but these errors were encountered:
This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.
Describe the feature
This might need RFC in the future, for now trying to describe the issue for the record.
Currently, SWC's rust packages (which are published in crates.io) do not follow semver. Instead,
use the latest versions to ensure build passed
. There were some rough edges but it worked mostly.With plugins, this becomes more challenging. There are various cases the recommendation cannot be followed,
inter-pkg version conflict when reference / import
swc_plugin
and other packages in the plugin code itselfi.e
swc_plugin
's transitiveswc_common
does not match to the direct dep'sswc_common
version. User have to look intoswc_plugin
's version tree, then match it with its direct import.Host - plugin version differences
Cases like Cannot use SWC plugins in Webpack loader plugins#48, where host have latest pkg with breaking changes to the version being used in plugins.
This gets more complex if we want to ensure compatibility across different host runtimes, for example
next-swc
does not use latest swc always, which can result like vercel/next.js#38428 . Currently there's no way to make plugin to be compatible between@swc/core
andnext-swc
if those 2 hosts are diverged.In the end, we may need to introduce some sort of semver compliant to prevent these. It needs some thought around how. Probably we'll need to create single
SDK
-like entrypoint pkg which includes all of the transitive deps, can be feature-flag controlled in compile time and those pkg ensures semver - all of rust binary should import those package only, any direct import to trasnsitive dep won't gaurantee semver in that case.Babel plugin or link to the feature description
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: