Chris Krycho

Yes! My own take here is that users should be able to import and name *types* like these as public API, but the public API import will be exactly and...

And with my TS hat on: we all agree that it was bad! Everyone is well aligned that it was a case of “recommended bad workarounds because there want a...

Regarding TypeScript lookups: FWIW, the string-keyed lookup is *way* more of a pain there than the proposed API here, in some hypothetical world where `@service bar` is allowed to change...

@ef4 point of clarification for my benefit: > 4. There are several things that feel like they _should_ work if the API is shaped this way, that could not be...

@NullVoxPopuli there's no difference between that and the import from the module whatsoever. (While TS differentiates between the type and the runtime object, JS only knows of the runtime object.)...

> Having worked a bit with Angular in the past few months, looking at how [dependency injection and services works there](https://angular.io/guide/architecture-services) was pretty interesting: > > ```ts > import MyService...

FWIW, on this point: > Today, if you need to override a service foo to add some functionality, you can create the `services/foo.js` file and you're done with it. I...

Much of this discussion has me wondering if it's not worth taking a step back and reconsidering the shape of this entirely. It's worth remembering that dependency injection and particularly...

I’d just like to *very* strongly second @ef4 here: > …the ideal amount of code you need to install a plugin is not zero lines. It's two lines (import it...

The *vast* majority of addons shouldn't need any build time integration anymore. Many addons which “have a build” still won’t need build-time integration in the sense they have historically: they...