\
**Category:** Ember CLI\
**Created:** [February 21, 2021, 5:24pm UTC](https://discuss.emberjs.com/t/fixing-htmlsafe-and-ishtmlsafe-deprecation/18639 "2021-02-21T17:24:21Z")\
**Posts on this page:** 3\
**Page:** 1
**Author:**  [@Igor\_Kvasnicka](https://discuss.emberjs.com/u/Igor_Kvasnicka)\
**Post date:** [February 21, 2021, 5:24pm UTC](https://discuss.emberjs.com/t/fixing-htmlsafe-and-ishtmlsafe-deprecation/18639/1 "2021-02-21T17:24:21Z")
Hi,
I recently upgraded to Ember 3.25.1 and I am trying to resolve deprecation [_Importing `htmlSafe` and `isHTMLSafe` from @ember/string_](https://deprecations.emberjs.com/v3.x/#toc_ember-string-htmlsafe-ishtmlsafe)
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:
```auto
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
---
**Author:**  [@rwjblue](https://discuss.emberjs.com/u/rwjblue)\
**Post date:** [February 21, 2021, 6:03pm UTC](https://discuss.emberjs.com/t/fixing-htmlsafe-and-ishtmlsafe-deprecation/18639/2 "2021-02-21T18:03:06Z")
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.
---
**Author:**  [@chriskrycho](https://discuss.emberjs.com/u/chriskrycho)\
**Post date:** [February 21, 2021, 6:06pm UTC](https://discuss.emberjs.com/t/fixing-htmlsafe-and-ishtmlsafe-deprecation/18639/3 "2021-02-21T18:06:31Z")
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](https://emberjs.github.io/rfcs/0706-deprecate-ember-global.html), 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.