diff --git a/st-embroider/2024/2026-01-13.md b/st-embroider/2024/2026-01-13.md new file mode 100644 index 00000000..81fec513 --- /dev/null +++ b/st-embroider/2024/2026-01-13.md @@ -0,0 +1,112 @@ +# 2026-01-13 + +Note Taker: Chris Manson +Time Keeper: Chris Manson + +## Attendees + +Add yourself to the list if you attend and check the box! + +- [x] Ed Faulkner (EF) +- [x] Chris Manson (CM) +- [x] Alex (A) +- [x] Preston Sego (PS) +- [ ] Simon Ihmig (SI) +- [x] Katie Gengler (KG) +- [ ] Krystan HuffMenne (KH) +- [x] Peter Wagenet (PW) +- [ ] James Davis (JD) +- [ ] Liam Potter (LP) +- [x] davidtaylor +- [x] tommyjr + + +## Topics + +### hosted ember-mcp? (disclaimer added since last week) <@NullVoxPopuli> + +- request came up again recently +- EF: we left this as needing an RFC +- (discussion about generating RFCs with LLMs) - not a great track record +- PW: it's not a LLMs vs no LLM - the problem is mostly about time +- + +### Anyone have a design for runtime macros features? <@NullVoxPopuli> + +- https://github.com/ember-cli/ember-app-blueprint/issues/175#issuecomment-3730560157 +- (recap about isTesting being a very simple macro that is intentionally) +- this is about using isTesting() in module scope +- KG: we have always discouraged checking isTesting in module scope - https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-ember-testing-in-module-scope.md +- CM: but that's Ember.isTesting +- EF: that should be extended to include macros isTesting() + +### https://github.com/ember-cli/ember-addon-blueprint/pull/127 publint <@NullVoxPopuli> + +- EF: seems ok and can go in the other RFC if needed + +### keepAssets doesn't handle all the CSS use cases we need <@NullVoxPopuli> + +- See: ember-welcome-page https://github.com/ember-cli/ember-welcome-page/pull/421 +- PS: Propose: https://github.com/jleeson/rollup-plugin-import-css for CSS handling -- author is easily nerd sniped +- EF: this aligns with our RFC that does import.meta.resolve +- EF: maybe we should have named this something else like makeItLegalToImportFile +- (long discussion) +- CM: what should actually be in the dist +- EF: the import.meta.resolve RFC defines what you should publish +- CM: that's what I thought - thanks for the confirmation +- EF: we need to be careful about edges out of css, the RFC is strict about JS -> assets but it's not clear that we should change anything else +- A: (question about what should be processed) +- CM: remember that everything + + +### Consider reverting --minimal and --no-compat https://github.com/ember-cli/ember-app-blueprint/pull/49#issuecomment-3740430054 <@mansona> + +- CM: discussion about the current state of this PR +- EF: this is an example of how we create thorns in our side +- there is value in this work as a feature flag - to figure out the +- EF: I agree that as a feature that we want to support forever it's too much +- EF: if we reverted this and opened the branch again to discuss landing these as feature flags +- PS: I'm PRing this as a `--experiemental` prefix to the flags is that ok? +- CM: I think we should revert this and reopen so we don't have to make the decision pressed up against a deadline +- EF: Agreed +- PS: we need a minimal app blueprint and we need it to be the default soon +- (loads of discussion) +- CM: I agree with PS, we should be aiming for a "pefect" application but we shouldn't be skipping any step between here and there +- we know what the next step is, the addon v2 by default is the next step +- A: we care about giving you out of the box everything that you need, even if I always remove ember-data +- PS: there is a `--no-ember-data` flag +- KG: that was also added without an RFC - that would have helped us track all the places that needed to update when things like the warpdrive rename +- + +### @ember/optional-features doesn’t work without a prebuild. In particular, this means that apps drop from async observers to sync observers. Roadmap says “can stay v1 with no impact” - should that be changed? <@davidtaylorhq> + +- https://github.com/emberjs/ember.js/blob/df4f25864d7d153be6ed231289f8fa8686247aab/packages/%40ember/-internals/environment/lib/env.ts#L127 BUT we did change the default in blueprints in 3.16 (with octane) https://github.com/ember-cli/ember-new-output/blob/v3.16.0/config/optional-features.json#L3 +- Original RFC did not cover changing existing ember apps: https://rfcs.emberjs.com/id/0494-async-observers “We currently believe this would be a breaking change that would prevent many users from adopting Octane or transitioning forward to tracked properties, which would be problematic and could divide the community.” + +- EF: we should work on not having ember-optional-features - too tied to ember versions +- all the things that it does should just be in +- CM: we discussed replacing this with macros +- EF: yes that's how you would do it - but only if it's a build time thing +- the new optional features doesn't even use the addon +- EF: we should just eliminate this and the need for it +- we should set the Ember ENV things (from optional features) in the v2 addon blueprint in a script tag +- we could flip the default in Ember + + +### Merge the backports for babel-plugin-ember-template-compilation <@mansona> + +- https://github.com/emberjs/babel-plugin-ember-template-compilation/pull/112 +- https://github.com/emberjs/babel-plugin-ember-template-compilation/pull/111 +- https://github.com/emberjs/babel-plugin-ember-template-compilation/pull/113 + +### compat modules polyfil for ember-engines <@void-malex> + +- A: are we happy with the approach of using a polyfill for the compat modules prefix + - https://github.com/ember-engines/ember-engines/pull/907/changes#diff-d4042b8bf2daf710597af580e04f15a41a52af5cc12614e8cc9a381f1e40b554R12 + - https://github.com/ember-engines/ember-engines/pull/907/changes#diff-bf74e24251994cddb3c9d94bfbfc7127b3146593b1c337a7f97ed74949f53615 +- EF: mostly ok +- (recap of the context of what we're talking about) +- EF: how do you prevent the polyfill from working in Vite +- A: it's in the include +- EF: but include works in embroider +