Skip to content
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

Understand scope for types #10151

Open
conartist6 opened this issue Jul 1, 2019 · 2 comments

Comments

Projects
None yet
2 participants
@conartist6
Copy link
Contributor

commented Jul 1, 2019

Is your feature request related to a problem? Please describe.
I am using babel to do custom transpilation on some typescript files. The input and output is typescript, but I need to make some changes in the middle. The problem is that when I look type identifiers, I can't do anything I'd like to with them. Babel doesn't understand how any of them reference each other, and it can't get there because there's no place to put the data. Types have scope, but they are not part of the runtime scope, and it seems unwise for babel blur the distinction between js scope and anything else.

Describe the solution you'd like
I propose either a typeScope structure, or support for arbitrary scope structures such as tsScope and flowScope, with the decision to be made based on whether it is possible to reconcile the scoping models for Typescript and Flow, while also considering any future type systems.

Describe alternatives you've considered
Currently the only alternative is to use the rather subpar typescript transformers API. It's already hard enough to learn how to write babel transformations given the relative lack of documentation, and learning typescript is even harder.

Teachability, Documentation, Adoption, Migration Strategy
Hopefully there would be nothing for end users to see. This API would be targeted at plugin authors, who could hopefully then write plugins capable of more advanced logic. In particular I would hope that it might eventually be possible to write a plugin which did a best-effort conversion of a typescript typedef file (.d.ts) to a flow typedef file (.js.flow) or visa versa.

@babel-bot

This comment has been minimized.

Copy link
Collaborator

commented Jul 1, 2019

Hey @conartist6! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community
that typically always has someone willing to help. You can sign-up here
for an invite.

@conartist6

This comment has been minimized.

Copy link
Contributor Author

commented Jul 1, 2019

It seems to me that there will likely be significant complexity in building these scope objects, which would probably belong in new plugins, along the lines of babel-plugin-scope-typescript and babel-plugin-scope-flow. These plugins would contain the logic that captures and isolates the nuances of scope in each language. The real question is, does either imply unique properties resultant data structure?

Both languages are capable of referring to runtime symbols (e.g. classes) in types, so any typeScope structure would need to be linkable to normal scope structures.

It is not immediately obvious in TS whether a symbol imported from another file is a type or runtime symbol. In flow it is. Still, this should not be troublesome. In both cases scope can capture the reference to the imported identifier, and the properties and parents of that identifier node will capture the rest of the information.

Both languages support parameterized functions, classes, and types. I don't foresee difficulty here, only benefit. Capturing scope information will make it clear whether a particular identifier is a generic type parameter, and if so which function, class, or type it belongs to.

Existing plugins which strip types would also want to prune out type scope if it is present.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.