Enable Glint by Default #976
Conversation
|
|
||
| There are some potential drawbacks to adopting Glint: | ||
|
|
||
| **Learning Curve:** Developers who are not familiar with TypeScript may face a learning curve when integrating Glint into their Ember projects. |
There was a problem hiding this comment.
counter point, in VSCode, TS is already enabled in JS by default in JS projects, so Developers may already be used to TS-aware JS projects, and would be less productive without the tsawareness
There was a problem hiding this comment.
We should definitely make sure that just adding Glint doesn't do anything unexpected in the editor or linting that requires additional immediate input. That should continue to remain purely opt-in beyond that point.
|
|
||
| We should verify that there are no redundancies between the Glint Language Server and the Ember Language Server used in IDEs. If there is, we should answer the following questions: | ||
|
|
||
| Should Glint Language Server features be merged into the Ember Language Server? Alternatively, should we remove the redundancy between them but keep them separate? |
There was a problem hiding this comment.
I do think it would be good to have only one language server to install.
There was a problem hiding this comment.
Is there any overlap? If not, there's still benefit in merging, but it does become a somewhat tangential concern.
|
|
||
| In the opinion of the authors of this RFC, the benefit of Glint outweighs the downsides of requiring the boilerplate. | ||
|
|
||
| Additionally, `.gts` is not supported for route templates by default, so that issue would need to be resolved, delaying the Glint recommendation further. |
There was a problem hiding this comment.
a note for readers, you can use gts in route templates via: https://github.com/discourse/ember-route-template
example:
|
I'm curious, how does this play with a project that's not using TS at all yet? |
|
|
||
| This RFC proposes adopting Glint as a default/recommended tool in the Ember.js framework. Glint is a static TypeScript-based template type checker that aims to improve developer experience and catch template-related errors at build time. By incorporating Glint into Ember.js, we can enhance type safety, provide better tooling, and encourage best practices when working with templates. | ||
|
|
||
| Adopting Glint as a default/recommended tool in Ember.js is a step towards improving developer experience, reducing errors, and promoting best practices in Ember.js template development. By integrating Glint and providing guidance, Ember.js can stay at the forefront of modern web development practices. |
There was a problem hiding this comment.
This sentence seems like a clear duplicate of the previous sentence and does not seem necessary.
-
This sentence: "is a step towards improving developer experience"
- Previous sentence: "that aims to improve developer experience"
-
This sentence: "reducing errors"
- Previous sentence: "catch template-related errors"
-
This sentence: "promoting best practices"
- Previous sentence: "encourage best practices when working with templates"
|
|
||
| Currently, we recommend Glint users enable the Glint Language Server in their IDE and disable the TypeScript Language Server to avoid duplicate errors. The Glint Language Server does not, however, currently have full feature parity with the TypeScript Language Server, so in doing so, users are losing some language server features. There is [work in progress](https://github.com/typed-ember/glint/issues/626) to rectify this issue. | ||
|
|
||
| ### Should we require that GTS is recommended before we recommend Glint? |
There was a problem hiding this comment.
If enabling Glint, requires no further out-of-the-box changes and doesn't introduce new surprising warnings, then this doesn't really seem to be necessary.
Co-authored-by: MrChocolatine <47531779+MrChocolatine@users.noreply.github.com>
|
Ed: Feels like a design gap that users won't get the experience unless they have the correct editor support. If we did that, this becomes an implementation detail of the language server. If you have a JS project with TS dependencies the built-in TS language server gives good behavior. If we want to provide something similar for templates, it shouldn't need changes in the project. Runspired: How much does this RFC change when we shift to Glint using Volar as a strategy? |
|
Giving all users, even non-TS apps, better feedback is a good goal here. But my question is why that should involve adding anything to the blueprint. By analogy with typescript, you get typescript-derived feedback in VSCode even when your project has no tsconfig or typescript dependencies. Could our language server not be similar? So long as all our packages contain type declarations, it seems like it would work without exposing any extra complexity to users. |
Rendered