Change htmlSafe and isHTMLSafe import path

[Serabe]

Deprecates importing it from @ember/string and adds the replacement
to @ember/template.

[Turbo87]

@ember/template 😉

[locks]

@Turbo87 re-👀

[Turbo87]

would like @rwjblue to verify though

[rwjblue]

See #37 (comment), we need the ability to have the same import map to different globals based on Ember version. Specifically, rolling this change out (mapping import { isHTMLSafe } from '@ember/template' to Ember.String.isHTMLSafe as is done in this PR) will trigger a deprecation for specific versions of Ember (once the Ember.String RFC is landed in an Ember version).

We need to have two entries for import { isHTMLSafe } from '@ember/template':

• one entry for Ember < 2.18 that maps (as this PR does) to Ember.String.isHTMLSafe
• one entry for Ember >= 2.18 (assuming the Ember.String deprecations land there) that maps to some other global location

[Serabe]

Will there be a way to provide the current version of Ember to all the projects using this data (specially eslint plugin, and babel plugin)?

[Turbo87]

I am quite worried about the complexity that will be introduced by this proposal. Especially since it's just working around the fact that we're still introducing new globals instead of using proper modules...

[rwjblue]

@Turbo87 - Have I missed something in my statement above? Am I making it more complicated needlessly?

[Turbo87]

Am I making it more complicated needlessly?

probably not needlessly, I'm just worried about adding more and more responsibilities to this package

[Serabe]

The only other solution I can think of is splitting the data among different packages which I think would be worse, but open to other options.

[rwjblue]

After rethinking here, I think we can actually a simpler thing.

Leave the current changes in the PR alone (deprecate: true with an alternative for import { isHTMLSafe, htmlSafe } from '@ember/string'), then add new entries (which are not deprecated) for import { htmlSafe, isHTMLSafe } from '@ember/template'. Since Ember will have to continue to ship Ember.String.{isHTMLSafe,htmlSafe} throughout its 3.x cycle, we can continue to map both the @ember/string and @ember/template versions back to Ember.String API's without issue.

@Serabe - Can you update this PR with those two new entries?

[Serabe]

I'll do it tonight.

[Turbo87]

shouldn't this PR also add the @ember/template equivalents?

edit: whoops, just noticed that that is what @rwjblue also suggested

[Serabe]

Rebased and updated. :(

[rwjblue]

Hmm, I think this needs to stay Ember.String.htmlsafe until we have a way to ensure that the transpilation will work for both [email protected] and [email protected] (soon to include this global).

Thoughts?

[Turbo87]

something like global: ["Ember._Template.htmlSafe", "Ember.String.htmlSafe"]?

but if we're going to make the format more complicated we should definitely document the format better 🤔

[Serabe]

I would change it and think how to do different transpilations depending on the version. Keeping an array would force us to transpile to something like:

var x = (Ember._Template && Ember._Template.htmlSafe) || (Ember.String && Ember.String.htmlSafe);

I rather keep two versions (0.x for Ember.String and 0.(x+y) for Ember._Template) than start doing that. In case we want to keep all in one version, I would rather see something like:

{
  "global": [{ "version_selector": "<2.18.0", "global": "Ember.String.htmlSafe"}, { "version_selector": ">=2.18.0", "global": "Ember._Template.htmlSafe"}]
}