add notes for tooling Jan 13th

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
+