Update dependency ember-css-modules to v2

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
ember-css-modules	1.3.4 -> 2.1.0

---

Release Notes

salsify/ember-css-modules (ember-css-modules)

v2.1.0

Added

• Glint types for {{local-class}} #​301 (thanks, @​SergeAstapov!)

v2.0.1

Compare Source

Fixed

• Avoid triggering (ember.js#19392)[https://github.com/emberjs/ember.js/issues/19392](https://redirect.github.com/emberjs/ember.js/issues/19392)2] when we produce synthetic class AttrNodes.

v2.0.0

Compare Source

This major release of Ember CSS Modules primarily removes support for deprecated patterns and updates our minimum support for other elements of the ecosystem.

Compatibility

Ember CSS Modules is now tested against the following as minimum supported versions:

• Ember 3.24
• Ember CLI 3.24
• Node 12

Older Ember and Node versions may incidentally work, but are no longer officially supported.

Removed

While ECM will still work for templates backed by Ember.Component classes, all special handling for such components' implicit root element has been removed, in line with the broader ecosystem shift to template-only and @glimmer/component components. This includes the following removals:

• the @localClassNames and @localClassName decorators
• support for localClassNames and localClassNameBindings properties
• the patchClassicComponent configuration flag

Special support for Ember.Component was deprecated in v1.5.0 of ember-css-modules; see the changelog for that release for further advice on migrating to newer Octane-based component APIs.

v1.6.2

Compare Source

No changes noted.

v1.6.1

Compare Source

v1.6.0

Compare Source

Added

• You can now pass patchClassicComponent: false in your ECM config to opt out of the deprecated monkeypatching of Ember.Component that will be removed entirely in 2.0 (thanks @​SergeAstapov!)

Fixed

• Modules whose path includes the name of the package they're in no longer cause issues when resolving @value and composes: directives (thanks @​eshirley and @​maxfierke!)

v1.5.0

Compare Source

Deprecated

• ECM's support for binding local class names on the root element of a classic Ember.Compnent (the localClassNames and localClassNameBindings properties and the @localClassName and @localClassNames decorators) has been deprecated and will be removed in the next major release. These APIs rely on reopening Ember.Component (which is itself now deprecated) and can be replaced by several alternative patterns. See the Upgrade Notes section below for migration suggestions.

Upgrade Notes

For classic @ember/component subclasses, ember-css-modules has had support for binding static and dynamic local class names to the component's root element using either .extend() or decorator syntax:

export default Component.extend({
  localClassNames: ['always-present'],
  localClassNameBindings: ['flipACoin'],

  flipACoin: computed(function() {
    return Math.random() > 0.5 ? 'yes-class' : 'no-class';
  }),
});

@​localClassNames('always-present')
export default class MyComponent extends Component {
  @​localClassName flipACoin = Math.random() > 0.5 ? 'yes-class' : 'no-class';
}

Both versions of these APIs are now deprecated, as:

1. they rely on monkey-patching Ember.Component, which is itself now deprecated
2. they're parallels of the classNames and classNameBindings APIs that are no longer relevant in modern Ember applications

Depending on your appetite for refactoring and modernizing, you might take one of three approaches to migrating off of these APIs:

1. Convert your components to use the modern @glimmer/component base class instead of @ember/component. Since Glimmer component templates have "outer HTML" semantics, there's no implicit root element for these APIs to apply to. See the Octane vs Classic cheat sheet for further details on the differences between classic and Glimmer components.
2. Use tagName: '' to remove the implicit root element from your classic component, then add a corresponding explicit root element to your template, where you can use local-class as you would for any other element.
3. Import the class name mapping from your styles module and use that with the classic classNames and classNameBindings APIs:

   import styles from './styles';
   
   export default Component.extend({
     classNames: [styles['always-present']],
     classNameBindings: ['flipACoin'],
   
     flipACoin: computed(function() {
       return Math.random() > 0.5 ? styles['yes-class'] : styles['no-class'];
     }),
   });

v1.4.0

Compare Source

Added

• We now support a wider range of dependencies that includes PostCSS 8 out of the box. Depending on your package manager, you'll likely see this upgrade take effect automatically when you update ECM, and you may see deprecation warnings for any older PostCSS plugins you're using.

Upgrade Notes

If you're using older PostCSS plugins or an older Node version and wish to continue using PostCSS 7, the appropriate dependency versions are still in range for ECM, and we still run tests against them. The easiest way to lock to those versions locally is likely with resolutions entries, which you can see an example of in test-package/old-app.

  "resolutions": {
    "ember-css-modules/broccoli-css-modules": "^0.7.0",
    "ember-css-modules/broccoli-postcss": "^4.0.3",
    "ember-css-modules/postcss": "^7.0.35"
  },

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.