Introduce "Ember Language Tooling Roadmap" RFC #1014
Conversation
|
|
||
| ## How we teach this | ||
|
|
||
| (This RFC section not applicable.) |
There was a problem hiding this comment.
I believe we'll need to address a couple of points here (depending on how much in depth we want to go considering this is a roadmap):
- If GlimmerX support is dropped: what communication is needed? At least it seems like there should be a notice on glimmerjs.com mentioning this.
- Do we expect current users to stay on old versions of language tooling?
- Will there be a change in how we should teach people to set up editor support in the guides?
There was a problem hiding this comment.
GlimmerX, afaict, wasn't even standard Glimmer. It was just an experiment from LinkedIn, i think (tho, someone correct me if this is wrong)
There was a problem hiding this comment.
@NullVoxPopuli this is my understanding as well. I opened an issue on GlimmerX for a maintainer to comment.
|
Overall I'm a big fan, it ties in nicely with our "focus on what we're good at and use the ecosystem" story. |
|
|
||
| Continuing to support the classic two-file approach to Ember components (optional .js/.ts component file backing the .hbs template) will be more difficult than only supporting .gjs/.gts files (in fact one of the motivators for the .gts format was to avoid the complexity/ambiguity of the multi-file approach). I have not reached the point of the Volar spike to know how practical/possible it is to represent the classic two file approach. | ||
|
|
||
| There have been some discussions in the community as to whether we should just cut ties with the two-file past, but given that language tooling for .gts/.gjs is not that great, there's been less motivation for people (including this RFC's author) to migrate their components to .gts until tooling "is ready", and even when it is ready, it's still a lot of work for companies to migrate their code to .gts. |
There was a problem hiding this comment.
We discussed this and my vote is that any new tooling is only focused on the future and happy path. People still needing to support older apps can use the older tooling.
it's still a lot of work for companies to migrate their code to .gts.
This burden should be eased once @void-mAlex finishes his codemod
There was a problem hiding this comment.
It will be easier to achieve the .gts/.gjs support milestone as its own unit of work, regardless of class-backed component support, so maybe we can revisit that later. Maybe I can update the RFC to separate gts support out as a more agreeable preliminary milestone.
|
|
||
| ### Proposal 4: Migrate Glint to provide editor completions, type-checking, etc, using a TS Plugin | ||
|
|
||
| Vue Language Tooling has deprecated their Language-Server-backed language tooling in favor of a TS Plugin -driven tooling (while continuing to maintain vue-tsc for actually compilation of files). |
There was a problem hiding this comment.
Would Glint continue to fulfil the same role that vue-tsc does for Vue? Does glint even get involved with compilation?
There was a problem hiding this comment.
For libraries, it's been needed to generate declarations, but support for gts is rough, and has many issues. I've been recommending post processing the declarations via
https://github.com/NullVoxPopuli/fix-bad-declaration-output
(Note tho that one of those issues is a TS issue rather than Glint, in that they don't believe in the concept of peer provided types)
|
|
||
| ## Drawbacks | ||
|
|
||
| There is some risk to placing such a heavy bet on Volar in case they take things in a direction that is not advisable or incompatible/inconvenient to Ember. If Volar takes things in an unseemly direction, we would have to use and maintain a fork of Volar. |
There was a problem hiding this comment.
I don't see this as a big risk, and even if this happens we can fork an Emlar or Vober version and we'll be back a the status quo of providing our own ecosystem specific tooling.
|
Yes please. 🥳 |
kategengler
added
S-Exploring
|
|
||
| This RFC provides a roadmap towards modernizing, unifying, and improving the Ember language tooling ecosystem. In particular, we recommend the following long term goals: | ||
|
|
||
| 1. Remove support of and any reference to GlimmerX from Glint |
There was a problem hiding this comment.
This appears to have happened in typed-ember/glint#716
There was a problem hiding this comment.
Yes; I'm feeling based on your feedback and others, including former Glint maintainers, that going through the full RFC process for this probably doesn't make much sense. I will probably close it shortly (though I'll continue to use the roadmap).
There was a problem hiding this comment.
with above in mind, maybe worth to convert to an issue under https://github.com/emberjs/tracking-polaris/issues
|
Closing, as this doesn't really need full RFC / approval. We've merged initial refactor to Volar in the Glint repo and will be tracking progress in this Roadmap Issue |
|
@machty looks like this didn’t get closed after you said “closing” … 🙂 |
Propose Ember Language Tooling Roadmap
Rendered
Summary
This pull request is proposing a new RFC.
To succeed, it will need to pass into the Exploring Stage), followed by the Accepted Stage.
A Proposed or Exploring RFC may also move to the Closed Stage if it is withdrawn by the author or if it is rejected by the Ember team. This requires an "FCP to Close" period.
An FCP is required before merging this PR to advance to Accepted.
Upon merging this PR, automation will open a draft PR for this RFC to move to the Ready for Released Stage.
Exploring Stage Description
This stage is entered when the Ember team believes the concept described in the RFC should be pursued, but the RFC may still need some more work, discussion, answers to open questions, and/or a champion before it can move to the next stage.
An RFC is moved into Exploring with consensus of the relevant teams. The relevant team expects to spend time helping to refine the proposal. The RFC remains a PR and will have an
Exploringlabel applied.An Exploring RFC that is successfully completed can move to Accepted with an FCP is required as in the existing process. It may also be moved to Closed with an FCP.
Accepted Stage Description
To move into the "accepted stage" the RFC must have complete prose and have successfully passed through an "FCP to Accept" period in which the community has weighed in and consensus has been achieved on the direction. The relevant teams believe that the proposal is well-specified and ready for implementation. The RFC has a champion within one of the relevant teams.
If there are unanswered questions, we have outlined them and expect that they will be answered before Ready for Release.
When the RFC is accepted, the PR will be merged, and automation will open a new PR to move the RFC to the Ready for Release stage. That PR should be used to track implementation progress and gain consensus to move to the next stage.
Checklist to move to Exploring
S-Proposedis removed from the PR and the labelS-Exploringis added.Checklist to move to Accepted
Final Comment Periodlabel has been added to start the FCP