-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Expose emitter with visitors and transforms #11561
Conversation
Conflicts: src/compiler/checker.ts src/compiler/emitter.ts src/compiler/transformers/module/module.ts src/compiler/transformers/module/system.ts src/compiler/transformers/ts.ts src/compiler/visitor.ts
Before this change, this would be rewritten to `namespace "typescript".factory {` by the build process, resulting in an invalid definition file.
@alexeagle Angular team may find this useful. |
Thanks @ivogabe. We intend to expose the API in future releases, but we have some cleanup work that needs to be done first. We are doing this right now, so hopefully we should have more details on the time line for this change in the next few weeks. |
Thanks for the reply, @mhegazy. Would it be possible to merge the PR before the cleanup, by temporarily marking all functions as internal? I guess that the problem is that the API will change during of the cleanup, but if all functions are marked as internal that wouldn't be a problem. Merging it earlier would prevent some merge conflicts and would allow me to use a custom build, that exposes everything, to experiment with the API, as I can't wait to use it.. Then I do need to accept the risk of future changes of course. Can you tell which parts will be refactored? |
I would rather we clean it up first before any one uses it. i would assuming using your local copy now would be an alternative.
We need to change the order of the transforms, and push some transforms out. we need to update the helper logic, and how they are handled, and we need to clean up the factory and emit interfaces. |
@mhegazy just wanna ping you on any update for this :) |
We have made a whole set of changes recently. including move stuff around into ES2017 and esNext transforms, moved module transformation to the correct place, etc... A few issues still remain, namely handling of helpers (@rbuckton has a PR for this), and handling of We also need to clean up the printer to be able to print any subtree, though this does not gate exposing the transformation api. Hopefully we should be able to do this soon. |
I could see this as also very useful for implementing constant folding as a third-party module. |
Any update on this @mhegazy? |
Handling |
@mhegazy Is there a way to already play around with it? Or would it be an option to clone this PR and then transition to the final implementation once exposed, as I would really need this to get further in a project. Edit: |
Can this be put on the roadmap for 2.3? May be this is somewhat related to the #1564 Generator support for ES3/ES5. |
Closing in favor of #13940 |
I hope that the emitter could be exposed, like requested in #10786. I played a bit with the API, and it appeared that it could be used easily, so I made this PR. With this change, people can write tools that emit or modify JavaScript or TypeScript code. I made the following changes:
emit(file: SourceFile, transformers: Transformer[] = nullTransformers, newLine = "\n")
emitFiles
tocreatePrinter
, so it can be used inemit
andemitFiles
factory.ts
, in a new namespacets.factory
.visitEachChild
Examples:
The result of both examples is:
function foo(x) { if (x === void 0)\n x = 2; return x * 3; }
Fixes #10786