Port code to ember-rfc176-data new format

[Serabe]

This PR adapts the code to the new format in
ember-cli/ember-rfc176-data#37

This also removes a line testing an old shims not ported to new format.

[Turbo87]

This also removes a line testing an old shims not ported to new format.

this is a problem, since we should still warn about this even if there is no equivalent in the new mappings... 🤔

[rwjblue]

Ya, we should explicitly support having deprecated: true without a replacement value.

[Serabe]

Then either the old-shims file should not be removed or the data that was lost in translation brought back.

[rwjblue]

Hmm, not sure I'm following. All of the old shims data is included in the new mappings.json file isn't it?

[rwjblue]

Chatted with @Serabe in slack about this, and summarized in ember-cli/ember-rfc176-data#37 (comment).

[Turbo87]

we might also want to think about adding an fromOldShims: true to the relevant entries, otherwise at some point this rule will start warning about deprecated imports that are not actually part of the old shims

[Serabe]

Right.

[rwjblue]

Ya, but I actually think a general rule for no-deprecated-modules is a better overall path forward anyways...

[Turbo87]

Ya, but I actually think a general rule for no-deprecated-modules is a better overall path forward anyways...

I tend to disagree. The ember-cli-shims are deprecated independent of the Ember version that is used, but the other things might depend on the Ember version. In other words: if I'm on an old Ember version I do want to disallow the old shims, but I might not want to disallow legitimate API that is not yet deprecated in the Ember version that I'm using.

[rwjblue]

In other words: if I'm on an old Ember version I do want to disallow the old shims, but I might not want to disallow legitimate API that is not yet deprecated in the Ember version that I'm using.

Yep, totally agreed. At the moment we only have things that should have always worked, but I totally agree that at some future time we could deprecate a module in favor of some replacement that doesn't exist for certain Ember versions. This doesn't mean my suggested path forward is wrong 😉, it just means we need more data than deprecated: true.

For deprecations as of a specific Ember version, we should encode that into the updated mappings.json file format. I'm thinking deprecated: '1.2.3' (where its as of that specific version, and we can check Ember version against this string)...

[Turbo87]

what we could do is have a static list of module paths in this plugin that were part of ember-cli-shims and only warn if we detect an import from such a module path. I'm not sure that information needs to live in the RFC data repo 🤔

[michalsnik]

I agree with @Turbo87, but having a static list of modules used in ember-cli-shims will make it impossible to automatically fix those imports to recommended ones wouldn't it?

[Turbo87]

but having a static list of modules used in ember-cli-shims will make it impossible to automatically fix those imports to recommended ones wouldn't it?

I don't understand why that would be a problem? 🤔

[Serabe]

I need to keep the force upgrade of ember-rfc176-data or the tests won't pass. I'll update once ember-rfc176-data has been updated.

[rwjblue]

Ready to update to point at ember-rfc176-data@0.3.0 now that it is published.

[Serabe]

@rwjblue done!

[rwjblue]

I don't think this should be needed any more...

[rwjblue]

Should probably still be ^0.3.0 (it just has the same effect as ~0.3.0 in this case)

[rwjblue]

I just updated with:

• removing the no-deprecated-module rule (for now, but will make separate PR preserving authorship for that after this lands)
• Fixing a few conflicts
• Inline data for no-old-shims rule

[Turbo87]

can you add a test for Ember.String.htmlSafe to check that we're handling the deprecated flag correctly?

[rwjblue]

can you add a test for Ember.String.htmlSafe to check that we're handling the deprecated flag correctly?

sure, also still working on a few of the remaining failures (seem related to destructuring)

[rwjblue]

can you add a test for Ember.String.htmlSafe to check that we're handling the deprecated flag correctly?

We already had a test for htmlSafe, I updated the expectation to the correct value...

[Turbo87]

hmm, about the htmlSafe, do we eventually need to care about the ember-source version that is used?

[rwjblue]

hmm, about the htmlSafe, do we eventually need to care about the ember-source version that is used?

yes, but not now 😄, both import { htmlSafe } from '@ember/string' and import { htmlSafe } from '@ember/template' currently point to Ember.String.htmlSafe