From aace14e077fcb01baab22a73667d3b8044e7ff38 Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Fri, 15 Dec 2023 14:38:31 -0500 Subject: [PATCH 01/14] Create 0000-deprecate-non-colocated-components.md --- ...0000-deprecate-non-colocated-components.md | 77 +++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 text/0000-deprecate-non-colocated-components.md diff --git a/text/0000-deprecate-non-colocated-components.md b/text/0000-deprecate-non-colocated-components.md new file mode 100644 index 0000000000..cefef1b3aa --- /dev/null +++ b/text/0000-deprecate-non-colocated-components.md @@ -0,0 +1,77 @@ +--- +stage: accepted +start-date: +release-date: +release-versions: +teams: # delete teams that aren't relevant + - cli + - data + - framework + - learning + - steering + - typescript +prs: + accepted: # update this to the PR that you propose your RFC in +project-link: +--- + + + +# Deprecate non-co-located components. + +## Summary + +Deprecates +- classic component layout +- pods component layout + +## Motivation + +> Why are we doing this? What are the problems with the deprecated feature? +What is the replacement functionality? + +## Transition Path + +> This is the bulk of the RFC. Explain the use-cases that deprecated functionality +covers, and for each use-case, describe the transition path. +Describe it in enough detail for someone who uses the deprecated functionality +to understand, for someone to write the deprecation guide, and for someone +familiar with the implementation to implement. + +## How We Teach This + +> Would the acceptance of this proposal mean the Ember guides must be +re-organized or altered? Does it change how Ember is taught to new users +at any level? +Does it mean we need to put effort into highlighting the replacement +functionality more? What should we do about documentation, in the guides +related to this feature? +How should this deprecation be introduced and explained to existing Ember +users? + +## Drawbacks + +> Why should we *not* do this? Please consider the impact on teaching Ember, +on the integration of this feature with other existing and planned features, +on the impact of the API churn on existing apps, etc. +There are tradeoffs to choosing any path, please attempt to identify them here. + +## Alternatives + +> What other designs have been considered? What is the impact of not doing this? + +## Unresolved questions + +> Optional, but suggested for first drafts. What parts of the design are still +TBD? From f1757801330b86da7854072b411707f6b1a88d6d Mon Sep 17 00:00:00 2001 From: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Date: Fri, 15 Dec 2023 15:16:24 -0500 Subject: [PATCH 02/14] Actually write the thing --- ...0000-deprecate-non-colocated-components.md | 77 ---------- ...0995-deprecate-non-colocated-components.md | 132 ++++++++++++++++++ 2 files changed, 132 insertions(+), 77 deletions(-) delete mode 100644 text/0000-deprecate-non-colocated-components.md create mode 100644 text/0995-deprecate-non-colocated-components.md diff --git a/text/0000-deprecate-non-colocated-components.md b/text/0000-deprecate-non-colocated-components.md deleted file mode 100644 index cefef1b3aa..0000000000 --- a/text/0000-deprecate-non-colocated-components.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -stage: accepted -start-date: -release-date: -release-versions: -teams: # delete teams that aren't relevant - - cli - - data - - framework - - learning - - steering - - typescript -prs: - accepted: # update this to the PR that you propose your RFC in -project-link: ---- - - - -# Deprecate non-co-located components. - -## Summary - -Deprecates -- classic component layout -- pods component layout - -## Motivation - -> Why are we doing this? What are the problems with the deprecated feature? -What is the replacement functionality? - -## Transition Path - -> This is the bulk of the RFC. Explain the use-cases that deprecated functionality -covers, and for each use-case, describe the transition path. -Describe it in enough detail for someone who uses the deprecated functionality -to understand, for someone to write the deprecation guide, and for someone -familiar with the implementation to implement. - -## How We Teach This - -> Would the acceptance of this proposal mean the Ember guides must be -re-organized or altered? Does it change how Ember is taught to new users -at any level? -Does it mean we need to put effort into highlighting the replacement -functionality more? What should we do about documentation, in the guides -related to this feature? -How should this deprecation be introduced and explained to existing Ember -users? - -## Drawbacks - -> Why should we *not* do this? Please consider the impact on teaching Ember, -on the integration of this feature with other existing and planned features, -on the impact of the API churn on existing apps, etc. -There are tradeoffs to choosing any path, please attempt to identify them here. - -## Alternatives - -> What other designs have been considered? What is the impact of not doing this? - -## Unresolved questions - -> Optional, but suggested for first drafts. What parts of the design are still -TBD? diff --git a/text/0995-deprecate-non-colocated-components.md b/text/0995-deprecate-non-colocated-components.md new file mode 100644 index 0000000000..142d0f71e2 --- /dev/null +++ b/text/0995-deprecate-non-colocated-components.md @@ -0,0 +1,132 @@ +--- +stage: accepted +start-date: 2023-12-15 +release-date: +release-versions: +teams: # delete teams that aren't relevant + - cli + - framework + - learning + - typescript +prs: + accepted: https://github.com/emberjs/rfcs/pull/995 +project-link: +--- + + + +# Deprecate non-co-located components. + +## Summary + +Deprecates +- classic component layout +- pods component layout + + +After "ember@6", only the following will be allowed: +- co-located components +- gjs / gts components + +## Motivation + +These older component layouts force build tooling to keep a lot of resolution rules around, and makes it hard for codemods and other community tooling to effectively work across folks' projects. + + +## Transition Path + +There are two types of paths to migrate off the old layouts +- use a currently supported multi-file layout (keeping separate `js`, `ts`, and hbs files) +- migrate the component entirely to the latest component format, `gjs`, `gts`, (aka `