-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUGFIX beta] Deprecate importing htmlSafe and isHTMLSafe from @ember/string #19339
[BUGFIX beta] Deprecate importing htmlSafe and isHTMLSafe from @ember/string #19339
Conversation
We typically don't backport deprecations into |
packages/ember/index.js
Outdated
Ember.String.htmlSafe = deprecateImportFromString('htmlSafe', htmlSafe); | ||
Ember.String.isHTMLSafe = deprecateImportFromString('isHTMLSafe', isHTMLSafe); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of returning a function that does the deprecation, can you make these a getter that issues the deprecation upon access (those getters would then return the original values)? There are other examples like that in this file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would look something like:
Object.defineProperty(Ember.String, 'htmlSafe', {
enumerable: true,
configurable: true,
get() {
// do the deprecation
// then return the normal value
}
});
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should htmlSafe
and isHTMLSafe
get separate deprecation ids? I just made up ember-string.htmlsafe-ishtmlsafe
. Is there a pattern I should be following here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also just invented the URL https://deprecations.emberjs.com/v3.x/#toc_ember-string-htmlsafe-ishtmlsafe
I'm not sure if there's a pattern I should follow there as well (I was looking at #19234).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should
htmlSafe
andisHTMLSafe
get separate deprecation ids? I just made upember-string.htmlsafe-ishtmlsafe
. Is there a pattern I should be following here?
Dealers choice (I think either is fine)😊
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also just invented the URL https://deprecations.emberjs.com/v3.x/#toc_ember-string-htmlsafe-ishtmlsafe
I'm not sure if there's a pattern I should follow there as well (I was looking at #19234).
We usually figure out the urls by making the PR and grabbing them from the running app. Once the deprecation guide PR is merged, we can ensure that the URL is correct, then we can land this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Deprecation app PR: ember-learn/deprecation-app#758
3.24 is also an LTS candidate, if that impacts any decision. |
@rwjblue I had based this on the approach used in #19234, but I like the getter approach better. Will update. As far as backporting to 3.24, my thinking is this usage has already been deprecated for some time (as of the docs change) there was just no deprecation warning ever added or mention of it on http://deprecations.emberjs.com (which has caused confusion, to the point where someone has even removed the usage from the type defs). It's only come to a head recently because of ember-data's new dependency on the |
As an another example of the confusion, here's a discussion from over a year ago: DefinitelyTyped/DefinitelyTyped#38571 (comment) |
I'm all for providing a definitive answer, ensuring the docs have been updated and the deprecation guide has landed does that sufficiently. Introducing deprecations in a patch release is just very bad form. For example, a decent number of apps and addon use "throw on deprecation" and releasing a new deprecation warning will start failing their CI. We have a train model for a reason, landing this now and pulling it into the current beta channel should be perfectly fine (especially RE: sending a clear signal). |
@rwjblue that makes perfect sense! Salsify is one of those apps! 😉 |
df9ce14
to
feab7f3
Compare
'Ember.String.htmlSafe is exported correctly' | ||
); | ||
}, /Importing htmlSafe from '@ember\/string' is deprecated/); | ||
assert.notEqual(glimmer.htmlSafe, undefined, 'Ember.String.htmlSafe is not `undefined`'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These asserts are based on
ember.js/packages/internal-test-helpers/lib/confirm-export.js
Lines 17 to 44 in 26f4aff
export default function confirmExport(Ember, assert, path, moduleId, exportName) { | |
try { | |
let desc = getDescriptor(Ember, path); | |
assert.ok(desc, `the ${path} property exists on the Ember global`); | |
if (typeof exportName === 'string') { | |
let mod = require(moduleId); | |
assert.equal(desc.value, mod[exportName], `Ember.${path} is exported correctly`); | |
assert.notEqual(mod[exportName], undefined, `Ember.${path} is not \`undefined\``); | |
} else if ('value' in desc) { | |
assert.equal(desc.value, exportName.value, `Ember.${path} is exported correctly`); | |
} else { | |
let mod = require(moduleId); | |
assert.equal(desc.get, mod[exportName.get], `Ember.${path} getter is exported correctly`); | |
assert.notEqual(desc.get, undefined, `Ember.${path} getter is not undefined`); | |
if (exportName.set) { | |
assert.equal(desc.set, mod[exportName.set], `Ember.${path} setter is exported correctly`); | |
assert.notEqual(desc.set, undefined, `Ember.${path} setter is not undefined`); | |
} | |
} | |
} catch (error) { | |
assert.pushResult({ | |
result: false, | |
message: `An error occurred while testing ${path} is exported from ${moduleId}.`, | |
source: error, | |
}); | |
} |
but had to be a little different because it's now a getter in the "reexport" (not strictly a reexport now, I guess) and a value in the original mod.
packages/ember/index.js
Outdated
since: { | ||
available: '3.25', | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you set enabled
instead of available
?
since: { | |
available: '3.25', | |
}, | |
since: { | |
enabled: '3.25', | |
}, |
Until the deprecation stages RFC is fully rolled out, we are just using enabled
for deprecations (it means that folks get the deprecation right away and don't have to opt in).
available: '3.25', | ||
}, | ||
until: '4.0.0', | ||
url: 'https://deprecations.emberjs.com/v3.x/#toc_ember-string-htmlsafe-ishtmlsafe', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that ember-learn/deprecation-app#758 is merged, can you double check the deployed URL to make sure this is right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Things seem to jump around after page load so you don't end up exactly in the right spot, but the anchor but the link does match what's in the TOC. This jumping issue seems to affect all the anchors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the jumping around is the code blocks rendering. I'll make an issue!
feab7f3
to
d9ec17a
Compare
Thank you @jamescdavis! |
As per RFC #236, this deprecates importing
htmlSafe
andisHTMLSafe
from@ember/string
.The tracking issue for RFC #236 says that these will be deprecated via linting, but the linked issue is only a docs change that doesn't make it clear that importing from
@ember/string
is deprecated. There has been much confusion around whether this is actually deprecated (especially with regard to the@ember/string
type definitions).I'm hoping this can be backported to 3.24 since the the string prototype extensions were deprecated in that version.