add tooling team notes for 5th May

st-embroider/2024/2026-05-05.md

@@ -0,0 +1,62 @@
+# YYYY-MM-DD
+
+Note Taker: 
+Time Keeper: 
+
+## 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)
+- [ ] Peter Wagenet (PW)
+- [ ] James Davis (JD)
+- [x] Liam Potter (LP)
+- [x] TommyJR
+
+## Topics
+
+### CI has been broken on embroider-build/embroider since 1st April (was that release week?) - can we get it to notify us in `#core-tooling`
+
+- KG: you should have permission - try it and let me know
+- if you copy the Github CI snippet from other things (like the tutorial) that should be all you need
+
+### ember-cli-htmlbarsapocolypse and ember-cli-babelapocolypse coming - not sure we expected this big cliff
+
+- CM: we knew about the ember-cli-htmlbars version problem - we're ok to just override
+- we might not be aware of the ember-cli-babel requirement - `@embroider/core` imports a different babel-plugin-ember-template-compilation depending on what ember-cli-babel an addon uses
+- EF: i forgot about this problem
+- (long discussion)
+- at a minimum we need to add ember-cli-babel to the list of things that need to get updated in the deprecation guide
+- CM: one of the problems is that the error is very bad
+- EF: we could just decide to use the newer ember-cli-babel during build that might work too
+- we could also release a patch for 
+
+
+### sideEffects hints (add to library blueprint?)
+
+- https://github.com/emberjs/ember.js/pull/21365 
+- (discussion about sideEffects)
+- EF: it's a bit hard to add this in general
+- KG: if we could statically lint this then the bundlers would be doing this
+- (more discussion about how to do this right)
+- EF: what is the benefit here? is there a good reduction?
+- PS: with my experiementation it's a massive change
+- (more discussion about rolldown)
+- EF: should we be putting this on the addon blueprint
+- PS: we can't really get benefits without type:module on v2 addons
+- (discussion about type:module)
+- CM: I'm pretty sure that type:module will give us everything that this PR is trying to do
+- PS: I'm running CI on this now to experiment
+
+### Route Manager RFC
+
+- (long discussion)
+- (note taker was participating in the discussion too much to take notes)
+- Short sumamry of the position: we need to make sure that there are 3 levels of "state" for a route - the route manager invokable that will always be 1-1 for a manager, the route invokable that will be called exactly once per route and re-used, and the context of route will update every time the route is entered.
+- CM: I had been focued so much on making sure that we supported experimentation with resources going forward that I didn't consider the experiments in terms of updating the router itself: e.g. being able to have two routes running at the same time (two pannels with the same route at the same time)