Skip to content

Commit a8b2d0c

Browse files
NullVoxPopuliNullVoxPopuli
authored
Merge branch 'main' into advance-rfc-1068
2 parents 27e8102 + a98ef9b commit a8b2d0c

6 files changed

Lines changed: 298 additions & 14 deletions

‎text/0931-template-compiler-api.md‎

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
---
2-
stage: released
2+
stage: recommended
33
start-date: 2023-05-31T00:00:00.000Z
44
release-date:
55
release-versions:
@@ -15,6 +15,7 @@ prs:
1515
accepted: 'https://github.com/emberjs/rfcs/pull/931'
1616
ready-for-release: 'https://github.com/emberjs/rfcs/pull/933'
1717
released: 'https://github.com/emberjs/rfcs/pull/1085'
18+
recommended: 'https://github.com/emberjs/rfcs/pull/1105'
1819
project-link:
1920
suite:
2021
---

‎text/0977-v2-app-format.md‎

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,8 +1,9 @@
11
---
2-
stage: ready-for-release
2+
stage: released
33
start-date: 2023-10-06T00:00:00.000Z
4-
release-date:
4+
release-date: 2025-10-15
55
release-versions:
6+
ember-cli: 6.8.0
67
teams:
78
- cli
89
- data
@@ -11,6 +12,7 @@ teams:
1112
prs:
1213
accepted: 'https://github.com/emberjs/rfcs/pull/977'
1314
ready-for-release: 'https://github.com/emberjs/rfcs/pull/1062'
15+
released: 'https://github.com/emberjs/rfcs/pull/1147'
1416
project-link:
1517
suite:
1618
---

‎text/1099-renderComponent.md‎

Lines changed: 9 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,15 @@
11
---
2-
stage: ready-for-release
2+
stage: released
33
start-date: 2025-05-01T00:00:00.000Z
4-
release-date:
4+
release-date: 2025-10-13
55
release-versions:
6+
ember-source: 6.8.0
67
teams:
78
- framework
89
prs:
910
accepted: 'https://github.com/emberjs/rfcs/pull/1099'
1011
ready-for-release: 'https://github.com/emberjs/rfcs/pull/1128'
12+
released: 'https://github.com/emberjs/rfcs/pull/1144'
1113
project-link:
1214
suite:
1315
---
@@ -101,9 +103,9 @@ export function renderComponent(
101103
}
102104
```
103105

104-
`RenderResult` is a subset of the currently a pre-existing `interface` from `@glimmer/interfaces`, but would be exposed as public API via the only the return type of `renderComponent`.
106+
`RenderResult` is a subset of the currently pre-existing `interface` from `@glimmer/interfaces`, but would be exposed as public API via the only return type of `renderComponent`.
105107

106-
It's shape is:
108+
Its shape is:
107109
```ts
108110
export interface RenderResult {
109111
/**
@@ -216,7 +218,7 @@ const render = modifier((element) => {
216218

217219
## How we teach this
218220

219-
`renderComponent` _is_ a low-level API, but it's use cases are powerful:
221+
`renderComponent` _is_ a low-level API, but its use cases are powerful:
220222

221223
### Micro Applications
222224

@@ -279,7 +281,7 @@ Combined with [RFC #931](https://github.com/emberjs/rfcs/pull/931), we can dynam
279281
```
280282

281283
> [!NOTE]
282-
> Depending on your application, you may want to consider sanitizing user input, so users don't inject their own script / sytle tags into your app.
284+
> Depending on your application, you may want to consider sanitizing user input, so users don't inject their own script / style tags into your app.
283285
> See: [DOMPurify](https://github.com/cure53/DOMPurify) and [Web Sanitizer API](https://developer.mozilla.org/en-US/docs/Web/API/Sanitizer) and [TrustedHTML](https://developer.mozilla.org/en-US/docs/Web/API/TrustedHTML)
284286
285287
### Integration with "islands"-based documentation tools
@@ -363,7 +365,7 @@ All renderComponents rendered within an ember app would share their reactivity.
363365

364366
Outside of ember projects, _currently_ if multiple `renderComponent`s are used from different ember-source versions (possible if someone pulls in, for example, two web components from different libraries which internally use `renderComponent`), the `renderComponent` usages would not be co-reactive with each other's data. This is something that would need to be resolved in the underlying _renderer_ and is out of scope for discussion in this RFC.
365367

366-
Repeat calls to `renderComponent` with the same element will _replace_ all contents on that element. This means if someone wants multiple apps to render on a page as siblings, they should create sibling elements to render each sub-app in to. This is to be consistent with `document.body` vs within an app's component's DOM content. A way to render sibling components _could_ be to use TextNodes (or CommentNodes) to attach `renderComponent` to, but will be considered outside the scope of this RFC. We can add behaviors and ergonomics things later. This RFC is more about the base functionality for `renderComponent`.
368+
Repeat calls to `renderComponent` with the same element will _append_ all contents on that element. This means if someone wants multiple apps to replace one another, they should manually manage the destruction of the previously rendered app before calling `renderComponent` with the same element again. This is to be consistent with `document.body` vs within an app's component's DOM content.
367369

368370
If apps are replaced by other apps (such as rendering into the same element multiple times), there is a risk of memory leak if the prior apps were not destroyed, and _if_ those previous apps have global state that would _need_ cleanup (global event listeners, etc).
369371

‎text/1101-deprecate-ember-vendor-bundles.md‎

Lines changed: 158 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,158 @@
1+
---
2+
stage: released
3+
start-date: 2025-05-13T00:00:00.000Z
4+
release-date:
5+
release-versions:
6+
ember-source: 6.10.0
7+
teams:
8+
- cli
9+
- framework
10+
- learning
11+
prs:
12+
accepted: 'https://github.com/emberjs/rfcs/pull/1101'
13+
ready-for-release: 'https://github.com/emberjs/rfcs/pull/1156'
14+
released: 'https://github.com/emberjs/rfcs/pull/1159'
15+
project-link:
16+
suite:
17+
---
18+
19+
<!---
20+
Directions for above:
21+
22+
stage: Leave as is
23+
start-date: Fill in with today's date, 2032-12-01T00:00:00.000Z
24+
release-date: Leave as is
25+
release-versions: Leave as is
26+
teams: Include only the [team(s)](README.md#relevant-teams) for which this RFC applies
27+
prs:
28+
accepted: Fill this in with the URL for the Proposal RFC PR
29+
project-link: Leave as is
30+
suite: Leave as is
31+
-->
32+
33+
<!-- Replace "RFC title" with the title of your RFC -->
34+
35+
# Deprecate Ember Vendor Bundles
36+
37+
## Summary
38+
39+
The published `ember-source` package contains several AMD-specific bundled builds
40+
of Ember that are appended to `vendor.js` in the classic build system.
41+
This RFC deprecates the following files:
42+
43+
- `ember.debug.js`
44+
- `ember.prod.js`
45+
- `ember-testing.js`
46+
- `ember-template-compiler.js`
47+
48+
Instead, Ember will be included in application builds as ES module library via `ember-auto-import`.
49+
50+
## Motivation
51+
52+
Maintaining the legacy AMD-specific bundled copies of Ember is no longer necessary.
53+
Modern Ember applications should consume Ember as ES modules, which aligns with
54+
the broader JavaScript ecosystem. This change simplifies the build pipeline and
55+
reduces maintenance overhead.
56+
57+
This deprecation will have no effect on applications using Embroider with
58+
`staticEmberSource: true` or Embroider v4 (Vite). It only impacts applications
59+
using the classic build system without Embroider.
60+
61+
## Transition Path
62+
63+
> This is the bulk of the RFC.
64+
65+
> Explain the design in enough detail for somebody
66+
> familiar with the framework to understand, and for somebody familiar with the
67+
> implementation to implement. This should get into specifics and corner-cases,
68+
> and include examples of how the feature is used. Any new terminology should be
69+
> defined here.
70+
71+
> Please keep in mind any implications within the Ember ecosystem, such as:
72+
>
73+
> - Lint rules (ember-template-lint, eslint-plugin-ember) that should be added, modified or removed
74+
> - Features that are replaced or made obsolete by this feature and should eventually be deprecated
75+
> - Ember Inspector and debuggability
76+
> - Server-side Rendering
77+
> - Ember Engines
78+
> - The Addon Ecosystem
79+
> - IDE Support
80+
> - Blueprints that should be added or modified
81+
82+
83+
### Classic Build System
84+
85+
We will introduce a new optional feature for projects to opt into consuming
86+
Ember as ES modules. Not having this optional feature enabled will result in
87+
a deprecation warning.
88+
89+
Addons that rely on accessing Ember from `treeForVendor` or on accessing Ember
90+
from vendor will need to update their implementation.
91+
92+
### Embroider v4 or with `staticEmberSource: true`
93+
94+
This deprecation will have no effect on these projects. They already consume Ember as ES modules.
95+
96+
## How we teach this
97+
98+
> What names and terminology work best for these concepts and why? How is this
99+
> idea best presented? As a continuation of existing Ember patterns, or as a
100+
> wholly new one?
101+
102+
> Would the acceptance of this proposal mean the Ember guides must be
103+
> re-organized or altered? Does it change how Ember is taught to new users
104+
> at any level?
105+
106+
> How should this feature be introduced and taught to existing Ember
107+
> users?
108+
109+
> Keep in mind the variety of learning materials: API docs, guides, blog posts, tutorials, etc.
110+
111+
### Deprecation Guide
112+
113+
Ember will no longer publish legacy AMD-specific Ember builds. To opt-in to
114+
consuming Ember as ES modules and clear this deprecation, enable the
115+
`ember-modules` optional feature by running `ember feature:enable ember-modules`.
116+
117+
This applies only to the classic build system or to Embroider < 4.0 without the
118+
`staticEmberSource: true` option. If you see this deprecation warning in these
119+
setups, please [open an issue](https://github.com/emberjs/ember.js/issues/new/choose).
120+
121+
Alternatively, you can also clear the deprecation by moving to Embroider v4 by
122+
running the [Ember Vite Codemod](https://github.com/mainmatter/ember-vite-codemod),
123+
but this may require additional changes to your project.
124+
125+
The AMD-specific Ember builds will no longer be published in next Ember major release
126+
and no longer be bundled into `vendor.js`, even on the classic build system. These files are:
127+
-
128+
- `ember.debug.js`
129+
- `ember.prod.js`
130+
- `ember-testing.js`
131+
- `ember-template-compiler.js`
132+
133+
- In rare cases, Addons were relying on accessing Ember from `vendor`. If you have
134+
addons that do so they will need to be updated to consume Ember as ES modules.
135+
136+
A known addon that previously relied on accessing Ember from `vendor` is
137+
[ember-cli-deprecation-workflow](https://github.com/ember-cli/ember-cli-deprecation-workflow).
138+
Please ensure you are on the latest version of this addon as that reliance has
139+
been removed.
140+
141+
## Drawbacks
142+
143+
> Why should we _not_ do this? Please consider the impact on teaching Ember,
144+
> on the integration of this feature with other existing and planned features,
145+
> on the impact of the API churn on existing apps, etc.
146+
147+
> There are tradeoffs to choosing any path, please attempt to identify them here.
148+
149+
## Alternatives
150+
151+
> What other designs have been considered? What is the impact of not doing this?
152+
153+
> This section could also include prior art, that is, how other frameworks in the same domain have solved this problem.
154+
155+
## Unresolved questions
156+
157+
> Optional, but suggested for first drafts. What parts of the design are still
158+
> TBD?

‎text/1121-extraneous-invisible-character-stripping.md‎

Lines changed: 8 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,14 +1,18 @@
11
---
2-
stage: accepted
2+
stage: recommended
33
start-date: 2025-07-09T00:00:00.000Z
4-
release-date: # In format YYYY-MM-DDT00:00:00.000Z
4+
release-date:
55
release-versions:
6+
content-tag: 4.1.0
67
teams:
78
- framework
89
prs:
9-
accepted: https://github.com/emberjs/rfcs/pull/1121
10+
accepted: 'https://github.com/emberjs/rfcs/pull/1121'
11+
ready-for-release: 'https://github.com/emberjs/rfcs/pull/1127'
12+
released: 'https://github.com/emberjs/rfcs/pull/1157'
13+
recommended: 'https://github.com/emberjs/rfcs/pull/1163'
1014
project-link:
11-
suite:
15+
suite:
1216
---
1317

1418
# Default Template invisible character Minification

‎text/1164-host-ember-mcp.md‎

Lines changed: 117 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,117 @@
1+
---
2+
stage: accepted
3+
start-date: 2026-01-26T00:00:00.000Z
4+
release-date: # In format YYYY-MM-DDT00:00:00.000Z
5+
release-versions:
6+
teams:
7+
- learning
8+
- cli
9+
prs:
10+
accepted: https://github.com/emberjs/rfcs/pull/1164
11+
project-link:
12+
suite:
13+
---
14+
15+
# Recommend hosting `ember-mcp` on emberjs.com
16+
17+
## Summary
18+
19+
Recommend `ember-mcp` as the default MCP server for Ember projects. The goal is simple: when people use AI tools, they should get current Ember APIs and modern patterns by default, not legacy advice.
20+
21+
## Motivation
22+
23+
AI assistants are now part of many workflows, but they regularly miss Ember-specific context. The common failures are predictable: classic-era patterns, wrong APIs for the Ember version in use, and shell commands that don’t match the repo’s package manager.
24+
25+
`ember-mcp` addresses this by giving AI tools a small set of focused capabilities:
26+
27+
- Search Ember docs (API, Guides, community)
28+
- Fetch targeted API references
29+
- Provide best-practice guidance for modern Ember
30+
- Provide version/migration info
31+
- Detect the correct package manager and suggest the right commands
32+
33+
The expected outcome is fewer wrong suggestions and less time spent “arguing with the bot.”
34+
35+
## Detailed design
36+
37+
MCP (Model Context Protocol) lets AI tools call external “tools” in a structured way. `ember-mcp` is an MCP server that exposes Ember documentation and related utilities.
38+
39+
### What we’re recommending
40+
41+
- The recommended package is `ember-mcp`.
42+
- The upstream project is https://github.com/ember-tooling/ember-mcp.
43+
44+
### Data source
45+
46+
`ember-mcp` loads and indexes aggregated Ember documentation at startup (API docs, Guides, community content, examples) from:
47+
48+
`https://nullvoxpopuli.github.io/ember-ai-information-aggregator/llms-full.txt`
49+
50+
### Client configuration
51+
52+
Any MCP-compatible client can run it via `npx`:
53+
54+
```json
55+
{
56+
"mcpServers": {
57+
"ember": {
58+
"command": "npx",
59+
"args": ["-y", "ember-mcp"]
60+
}
61+
}
62+
}
63+
```
64+
65+
### “Hosted” expectation
66+
67+
A public endpoint: `https://mcp.emberjs.com` (or similar) for the latest version
68+
69+
And then for versions:
70+
- `https://mcp.emberjs.com/beta`
71+
- `https://mcp.emberjs.com/v6.10.x`
72+
- `https://mcp.emberjs.com/v6.8.x`
73+
- etc
74+
75+
76+
## How we teach this
77+
78+
- Add a short “AI-assisted development” section to the Guides: what MCP is, when to use it, and the one configuration snippet above.
79+
- Add `ember-mcp` to the emberjs.com tooling page alongside Ember Inspector and linting tools.
80+
- Publish a short announcement post focused on practical examples (upgrades, API lookups, best practices).
81+
82+
## Disclaimer and safety
83+
84+
The ember-mcp server is a read-only source of documentation. The server itself does not offer any mutation actions. But like any MCP server, it may suggest a command to your agent that your agent will run, and you need to be responsible for securing your environment against dangerous or destructive actions by your agent.
85+
86+
This includes (but isn’t limited to):
87+
88+
- Deleting code
89+
- Deleting folders/files outside of your project
90+
- Unintended modifications to your codebase
91+
- Other adverse effects (including damage to your OS or machine)
92+
93+
It’s important to be explicit about responsibility: MCP implementations and their maintainers are not responsible for damage caused by running generated commands or applying generated changes.
94+
95+
Practical guidance:
96+
97+
- Review commands and diffs before applying them.
98+
- Use version control and keep backups.
99+
- Prefer running tools with least privileges (and in disposable environments when possible).
100+
101+
## Drawbacks
102+
103+
- Ongoing maintenance: `ember-mcp` needs regular updates as docs and best practices change.
104+
- Trust/safety: it’s a tool surface for AI agents; docs should encourage reviewing output and using version control.
105+
- Dependency on the aggregator URL staying available and current.
106+
107+
## Alternatives
108+
109+
- Do nothing (developers keep getting inconsistent, often outdated Ember advice).
110+
- “Just write better docs” (helps, but doesn’t give AI tools structured access).
111+
- Build editor-specific integrations (more maintenance, less portable than MCP).
112+
113+
## Unresolved questions
114+
115+
- Q: What’s the policy for changes to the doc aggregator source and inclusion criteria?
116+
- write more docs on emberjs.com
117+
- write blog posts

0 commit comments

Comments
 (0)