[Question] Tree shaking services

I recently created a PR for an addon which removed the app re-export for a service that’s considered private API and replaced it with an injection string that uses the namespaced name (@service('ember-breadcrumb-trail@breadcrumbs') breadcrumbs).

This almost worked perfectly, but I noticed the CI job for embroider optimized failed. Looking more closely at it, it seems the service is not part of the final bundle so somewhere during the build process it gets marked as unneeded and dropped. I found this surprising since I explicitly inject it in multiple helpers.

I looked around at the documentation and specification but couldn’t really find an answer to how the code analysis works. Does Embroider look at container lookups when analyzing the code?

While experimenting I noticed that explicitly importing and registering the service in the container does fix the problem (with the class import being the trigger I guess). Is this what’s required to make services work that aren’t re-exported for the app folder?

I don’t think it’s a major issue since not re-exporting a service seems like a niche use-case and most addons use a - prefixed service name for private services instead. I just wanted to verify that this is intended behavior.

[ef4]

Does Embroider look at container lookups when analyzing the code?

No, it doesn’t. In general they aren’t statically analyzable.

A lot of the common cases are analyzable, but that leaves behind some painful and surprising edge cases that we would either need to make into annoying build errors or just let apps break.

I’m open to adding a staticServices option so people can experiment with getting fully static analysis of services, but nobody has prioritized working on that at the moment.

While experimenting I noticed that explicitly importing and registering the service in the container does fix the problem

Yes, you can manage it directly like that and it will work.

Going forward, I hope people will help design improvements to Ember’s API in this area to help making it easier for tooling (including both Embroider and TypeScript) to statically understand the dependency injection system).

[Windvis]

@ef4 Thank you, this has been very educational!