Fixing htmlSafe and isHTMLSafe deprecation

Ember CLI
1

Hi,

I recently upgraded to Ember 3.25.1 and I am trying to resolve deprecation Importing htmlSafe and isHTMLSafe from @ember/string

So wherever I was using

import { htmlSafe, isHTMLSafe } from '@ember/string';

I changed the import to

import { htmlSafe, isHTMLSafe } from '@ember/template';

Looks like a pretty straightforward fix - but then when I looked at the code generated in app.js I see code like this:

 return Ember.String.htmlSafe(resultWidth);

It looks like the old @ember/string import is being used…

There are also tons of deprecation messages in Ember Inspector suggesting that I should fix this, even though… well I did, but it looks like during the build process, the wrong function from the wrong @ember/string package is being used…

Did you ever encounter similar problem or can you please suggest what should I do?

thanks a lot

1 Like
2

The deprecation in 3.25 was flawed, and basically has no way to resolve (changing the import doesn’t fix it, due to transpilation details).

We have reverted the deprecation and will release that in a future 3.25 patch release.

1 Like
3

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.