ember-css-modules/v2.1.0

What's Changed

• Expanding embroider test coverage by @ef4 in #277
• Add Glint template registry for local-class helper by @SergeAstapov in #301
• Exclude development stuff from Snyk analysis by @dfreeman in #319
• Bump version for release by @dfreeman in #320

New Contributors

• @ef4 made their first contribution in #277

Full Changelog: v2.0.1...ember-css-modules/v2.1.0

v2.0.1

Fixed

Avoid triggering ember.js#19392 when we produce synthetic class AttrNodes.

v1.6.2

No changes noted.

v2.0.0

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.0

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 @Eric162 and @maxfierke!)

v1.5.0

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

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"
  },

v1.3.4

Fixed

• Ensure styles from addons that define a custom moduleName use correct import paths (#220; thank you @timlindvall!)

v1.3.3

Fixed

• Ensure addons use the host app's generateScopedName for consistency if they don't have their own configured.

Eventually Consistent

Fixed

• Ensure ember-css-modules is initialized before ember-cli-htmlbars. This almost always was coincidentally the case already, but ordering constraints from other addons could cause ECM to init later, causing local-class in colocated templates not to be processed, as in ember-concurrency-async#4