add notes for tooling 20th Jan

st-embroider/2024/2026-01-20.md

@@ -0,0 +1,60 @@
+# YYYY-MM-DD
+
+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)
+
+## Topics
+
+### Quick update on the Route Manager API work - direction and current analysis focus <@nickshot or @mansona> 
+
+- (update on the current analysis)
+- KG: I thought we were not intending to implement the current router with a manager 
+- CM: not really, we intend to allow zebra striping by wrapping the old thing with a full manager api
+- (discussion about capabilities)
+- next steps - capture the transition object in the same level of detail
+
+### Config access <@kategengler> 
+
+- Prompted by https://github.com/cibernox/ember-basic-dropdown/pull/1020
+- KG: addons are all coming up with their own boilerplate for config environment
+- we should discuss how this should be done and where to document this
+- PS: once we get past compat there is a good thing in babel macros
+- EF: that's not the same thing - there is often confusion about this
+- the referenced PR is all about runtime config
+- we have never designed the new thing - we could have a nice key-value thing that is namespaced by addon
+- having a module that addons read isn't how modules work
+- we could teach people how to do this the Vite way (environment variables)
+- we need to solve 2 things
+  - how do app developers swap behaviours based on build
+  - and how do addons consume app config
+- KG: it's nice that config/environment.js is "one place" and we don't need to track down all the random places
+- EF: agreed
+- another thing to consider is that if every addon imports something that sets a config it side-steps splitting logic
+- CM: (mentioned that you can use owner.lookup to get things)
+- PS: no you need to do `owner.resolveRegistration('config:environment')` because it's not the same
+- EF: that could be contributing to the confusion
+- KG: maybe this is just a communication thing then
+- CM: but I think it could be simpler to understand and teach
+- EF: it could just be a service that does something similar
+- we could allow the app to define a config in the old or new way, but the addons would use a single api
+- (discussion of the current state of things again)
+- EF: katie is right, the key thing here is a communication problem
+- there could be some benefit to import a function from your addon to solve type problems
+- it could just be a type and not a real implementation
+- CM: to wrap up - if someone came to us now asking how to migrate to a v2 addon should we point them to the owner.resoveregistration idea?
+- EF: yes that sounds good, it's not an API we can break any time soon anyway