-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make core transform isomorphic to run in plugin context also #4826
Comments
I think it's better to allow using |
Is this intended to support the case where e.g. I have a custom plugin which I want to run after transform of JSX to JS? If that were possible, it would simplify some custom plugins a lot. |
No. This'll allow some core transforms run in plugins instead. The order of transform between core / plugin won't change regardless. |
Ah I see. Thanks for clarifying. But is it the intent that a custom plugin can call an SWC transform pass itself (e.g. JSX to JS) before running it's own custom visitor? This is what I'd understood from "it is possible to run any existing core transform visitor as needed prior to run custom pass" - but maybe I'm misunderstanding? |
Yes, that's correct. But again, this doesn't mean anything aronud actual transform execution order between core / plugin and if core transform omits based on plugin's behavior or not. Certain plugin can try some core transform in its transform pass, but the execution order of plugin / core transform itself won't change. |
Describe the feature
There are some possible needs for the plugin who want to visit some state of AST after a certain transform phase completes.
In the case of custom transform (via before_custom_pass) it is possible to run any existing core transform visitor as needed prior to run custom pass, then run swc core's transform. It is probably not efficient in some aspects, but it is allowed. However, some visitors may not be allowed to chain certain visitor in the plugin context. Notably some rely on globals, handlers, and other few more plugin sdk provides proxy instead of host.
Ideally, we'd like to provide identical experiences between plugin / custom pass. We may need to update few core transform visitors, mostly under _compat to use proper context to allow this. Probably this is ad-hoc bases as someone need to use it, instead of trying to make everything at once.
In case of babel since context is always same under node.js, plugin author can freely duck-typing like
In our case it's not possible for the plugin.
Babel plugin or link to the feature description
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: