Advance RFC #0779 "First-Class Component Templates" to Stage Recommended

[emberjs-rfcs-bot]

Advance #779 to the Recommended Stage

Rendered

Summary

This pull request is advancing the RFC to the Recommended Stage.

• PR to Accepted Stage: First-Class Component Templates #779
• PR to Ready For Release Stage
• PR to Released Stage

An FCP is required before merging this PR to advance.

Recommended Stage Summary

The "Recommended" stage is the final milestone for an RFC. It provides a signal to the wider community to indicate that a feature has been put through its ecosystem paces and is ready to use.

To reach the "Recommended" stage, the following should be true:

If appropriate, the feature is integrated into the tutorial and the guides prose. API documentation is polished and updates are carried through to other areas of API docs that may not directly pertain to the feature.

If the proposal replaces an existing feature, the addon ecosystem has largely updated to work with both old and new features.

If the proposal updates or replaces an existing feature, high-quality codemods are available.

If needed, Ember debugging tools as well as popular IDE support have been updated to support the feature.

If the feature is part of a suite of features that were designed to work together for best ergonomics, the other features are also ready to be "Recommended".

Any criteria for "Recommended" for this proposal that were established in the Ready For Release stage have been met.

An FCP is required to enter this stage. Multiple RFCs may be moved as a batch into "Recommended" with the same PR.

Checklist to move to Recommended

• Criteria specific to this feature: Any additional criteria for "Recommended" for this proposal that were established in the Ready For Release stage have been met.
• Tutorial: If appropriate, the feature is integrated into the tutorial.
• Guides: If appropriate, the feature is integrated into the guides prose.
• API Docs: API documentation is polished and updates are carried through to other areas of API docs that may not directly pertain to the feature.
• Addon Ecosystem: If the proposal replaces an existing feature, the addon ecosystem has largely updated to work with both old and new features.
• Codemods: If the proposal updates or replaces an existing feature, high-quality codemods are available.
• Debugging Tools: If needed, Ember debugging tools (e.g. Ember Inspector, Deprecation Workflow) have been updated to support the feature.
• IDE Support: If needed, popular IDE support has been updated to support the feature.
• Engines, SSR: If needed, ecosystem feature such as Ember Engines, SSR support have been updated to support the feature.
• Blueprints: Blueprints have been updated to support the feature and to reflect the new best practices implied by this feature.
• Linting: Lint rules have been updated or added or removed to support the feature and to reflect the new best practices implied by this feature.
• Deprecations: If this feature implies that other features are no longer best practice, RFCs have been created to deprecate those features.
• Blog Post: Consider if a blog post should be written to introduce this feature to the community.
• Feature Suite: If the feature is part of a suite of features that were designed to work together for best ergonomics, the other features are also ready to be "Recommended".
• FCP to Recommended: This PR has been converted from a draft to a regular PR and the Final Comment Period label has been added to start the FCP.

Criteria for moving to Recommended (required)

<-- Copy and paste the criteria for "Recommended" from the Ready For Release stage here -->

A set of criteria for moving this RFC to the Recommended Stage, following release:

1. Update Guides content.
2. Update Tutorial content.
3. Ensure a basic level of ember-inspector support.
4. Document and/or simplify editor integrations (like having a single VSCode package, etc). Ex: If you start with tutorial or guide do you get a good editor experience?
   • add glint to Ember Extension Pack now that it works for all apps
5. Get a stable release of the currently-unstable version of Glint (volar-based).
6. Ensure generators are compatible with template-tag. ([FEATURE] Strict component blueprint support ember.js#20862)
7. Ensure there are no remaining problems with our default lint rules in template-tag.
8. Generator to upgrade from template-only to class-based (perhaps nice-to-have, should confirm template only is default)
9. Document that addons should document where to import their components/etc (Add spot in generated README)
10. API docs likely refer to handlebars
11. --strict should be default true for classic blueprint in 6.8, as well as v2 blueprint ember-cli/ember-cli#10827

[mansona]

From the RFC Meeting. We're agreed that the acceptance criteria for the checkbox Document and/or simplify editor integrations (like having a single VSCode package, etc). Ex: If you start with tutorial or guide do you get a good editor experience? actually includes the desire to have glint v2 in the default addon pack for Ember

Comment from the meeting: "We could progress this RFC faster if we just installed typescript, @glint/ember-tsc, and added a jsconfig.json file"

Note: There might be some issues with using jsconfig.json instead of a tsconfig.json in IDEs such as VSCode

Todo

• the bug where JS apps show errors without npm:typescript installed and without a tsconfig.json needs to be fixed
  • Support environments with no tsconfig or jsconfig typed-ember/glint#1052
  • Skip TypeScript activation and patching for GJS/GTS projects without tsconfig/jsconfig typed-ember/glint#1076
  • (feel free to add other PR links here)
• figure out if we would need @glint/template or @glint/ember-tsc to be installed in the blueprint and if there are any ramifications for JS only projects (we do not)

[ef4]

Glint now works out-of-the-box for JS-only projects.

[ef4]

Once Ember Extension Pack ships with glint, the remaining task here is a final pass through the docs (for things like removing --strict where it's not required, and places where the API docs are using non-strict patterns). And the related RFCs like the get/set testing patterns are now unblocked by this RFC and should also be reviewed for docs content.

[evoactivity]

Extension Pack has been released with Glint 2.