This is a bit of a tricky/quirky area that is slowly in the process of being straightened out. The modules Ember exposes currently do not map directly to modules on disk, but instead are compiled (via a Babel transform) to a final target. On the specific version you’re on, that target uses the Ember global with the
String value. This isn’t a thing you have to worry about on your end, though: it is only a concern of the compilation process, and your final build is fine. If I had to guess, I’d guess the warnings you’re seeing in Inspector are from dependencies which are not yet updated. If that’s not true, and the deprecations are from your code, that’s probably a bug! Edit: @rwjblue’s comment confirms it is a bug; he posted while I was typing! Sniped by Rob as always!
With the recent deprecation of using the
Ember global, we’re unblocked from moving to actually publishing modules on disk to match the names of the packages in line with the norms from the Node and broader front-end ecosystem. This is also an explicit goal of the Embroider effort and its updated design for publishing Ember addons (including Ember itself, which is an addon, just a really important one!): what we publish to npm should be able to be resolved by tools which understand normal Node imports.
For a tiny additional bit of context/background: the modules specification actually intentionally doesn’t specify what a given module string resolves to. While the Node layout has become conventional and default (and is a good one!) for front end as well as server, when Ember adopted modules, that wasn’t yet the case (we still had Bower in the mix back then!). The Ember implementation today is fully compliant with the modules specification; it’s just out of step with the broader ecosystem. That’s what the aforementioned Embroider effort will help with, and that’ll make it easier for us to use good tools from the rest of the rest of the front-end ecosystem.