Ember-flavored support for CSS Modules. For an overview of some of the motivations for the CSS Modules concept, see this blog post.
If you have ideas or questions that aren't addressed here, try #topic-css on the Ember Discord Server.
ember install ember-css-modulesWhen you build a component, you drop a .js file and a .hbs file in your app directory, and your tooling takes care of the rest. Babel takes your fancy ES6 module and restructures it into nice browser-friendly code, while still giving you isolation and modularity guarantees. Meanwhile, the rest of the Ember CLI build pipeline picks up these new files and automatically incorporates them into your final JS artifact. And when it's time to come back and tweak your component, you (just like the Ember resolver) know exactly where those files live based just on the name of the component.
With ember-css-modules, your styling is a first-class citizen alongside your templates and JavaScript. You have one .css file per component (or route controller), in the same structure you're already using in the rest of your app. Every class you write is local to that file by default, with explicit mechanisms for opting into sharing, just like your JavaScript modules. And just like all your JS modules are automatically included in <app-name>.js, your CSS modules will automatically be included in <app-name>.css.
With ember-css-modules, you define styles on a per-component (or -controller) basis. You define these styles using the same file layout you use for templates; for example, in pod structure you'd put styles.css alongside template.hbs in the component's pod. The classes in that stylesheet are then automatically namespaced to the corresponding component or controller. In order to reference them, you use the local-class attribute rather than the standard class.
/* app/components/my-component/styles.css */
.hello-class {
font-weight: bold;
}Similarly, if you were styling e.g. your application controller, you would place your styles alongside controller.js in <podModulePrefix>/application/styles.css.
In Octane apps, where component templates can be colocated with their backing class, your styles module for a component takes the same name as the backing class and template files:
/* app/components/my-component.css */
.hello-class {
font-weight: bold;
}In the example above, hello-class is rewritten internally to something like _hello-class_1dr4n4 to ensure it doesn't conflict with a hello-class defined in some other module.
For cases where class reuse is desired, there's the composes property. Suppose you have a title in your component that you'd like to inherit your app-wide "secondary header" styling, which itself uses generic styling shared by all headers:
/* app/styles/headers.css */
.header {
font-weight: bold;
text-decoration: underline;
}
.secondary-header {
composes: header;
color: #339;
}/* app/components/my-component/styles.css */
.component-title {
composes: secondary-header from 'my-app-name/styles/headers';
background-color: #eee;
}In the template for my-component, an element with local-class="component-title" will end up with an actual class string like _component-title_1dr4n4 _secondary-header_1658xu _header_1658xu, incorporating styles from all of the composing classes.
Note that you may also use relative paths to specify the source modules for composition.
Finally, you can compose local classes from global un-namespaced ones that are provided e.g. by a CSS framework by specifying global as the source of the class:
/* vendor/some-lib.css */
.super-important {
color: orange;
}/* app/components/my-component/styles.css */
.special-button {
composes: super-important from global;
}Currently the local-class attribute is honored on HTML elements and component invocations, e.g. <div local-class="foo {{bar}}"> and {{input local-class="baz"}}. It is not (currently) supported in subexpressions like the (component) helper.
If you need to access a local class in a template in other scenarios (such as passing in a class name as a property or reusing a class from another module), there is also a local-class helper you can use. For example, the "secondary-header" example above can be written as:
Note that the from parameter is optional; by default classes will come from the current module, as with the local-class attribute.
In a JavaScript context, the class mappings can also be imported directly from whatever path the corresponding CSS module occupies, e.g.
import styles from 'my-app-name/components/my-component/styles';
console.log(styles['hello-class']);
// => "_hello-class_1dr4n4"Note: by default, the import path for a styles module does not include the .css (or equivalent) extension. However, if you set includeExtensionInModulePath: true, then you'd instead write:
import styles from 'my-app-name/components/my-component/styles.css';Note that the extension is always included for styles modules that are part of an Octane "colocated" component, to avoid a conflict with the import path for the component itself.
Some libraries provide explicit class names as part of their public interface in order to allow customization of their look and feel. If, for example, you're wrapping such a library in a component, you need to be able to reference those unscoped class names in the context of your component styles. The :global pseudoselector allows for this:
.my-component :global(.some-library-class) {
color: orange;
}For more details on :local and :global exceptions, see the CSS Modules documentation.
For exposing data other than class names across module boundaries, you can use @value.
/* app/styles/colors.css */
@value primary-color: #8af;
@value secondary-color: #fc0;/* app/some-route-pod/styles.css */
@value primary-color, secondary-color from 'my-app-name/styles/colors';
.blurb {
color: primary-color;
background-color: secondary-color;
}Note that values are also exposed on the styles object for a given module, so they are also accessible from JavaScript if you need to coordinate between the two. As a contrived example:
// app/some-route-pod/controller.js
import styles from 'app/some-route-pod/styles';
export default Ember.Controller.extend({
logColor() {
console.log('primary color is', styles['primary-color']);
}
});Helper {{local-class}} has proper Glint types,
which allow you when using TypeScript to get strict type checking in your templates.
Unless you are using strict mode templates (via first class component templates), you need to import the addon's Glint template registry and extend your app's registry declaration as described in the Using Addons documentation:
import '@glint/environment-ember-loose';
import type EmberCssModulesRegistry from 'ember-css-modules/template-registry';
declare module '@glint/environment-ember-loose/registry' {
export default interface Registry extends EmberCssModulesRegistry, /* other addon registries */ {
// local entries
}
}You can also use ember-css-modules in addons that expose components to their consuming application. To do this you'll need to move ember-css-modules out of devDependencies and into dependencies in your addon's package.json (see issue #8).
Note also that your addon must have an addon/styles directory in order to trigger CSS processing in Ember CLI. In order for the directory to be preserved when you publish your addon, you can create an empty .placeholder file (.gitkeep won't work; by default, the .npmignore for your addon will prevent files with that name from being published).
Ember CSS Modules has a plugin ecosystem that allows for people to bundle up common configurations and extensions for easy reuse and distribution. For example, if your organization has a common set of PostCSS plugins you always use, you could package those as a plugin and then just drop that into any Ember project and have it automatically take effect.
For details on developing your own, see the plugins mini-guide. You can also look at the following examples of what plugin implementations can look like:
You can find a list of all publicly available plugins by browsing the npm ember-css-modules-plugin keyword.
Details about specific advanced configuration options are broken out into smaller mini-guides that each focus on a single topic:
- Using CSS Modules with Tailwind CSS
- Using CSS Modules with other preprocessors like Sass or Less
- Working with PostCSS plugins
- Module ordering
- Defining values at build time with virtual modules
- Authoring ember-css-modules plugins
For applications, custom configuration for ember-css-modules may be specified in ember-cli-build.js:
new EmberApp(defaults, {
// ...
cssModules: {
// config
}
});For addons, configuration may be specified in your addon's index.js instead:
module.exports = {
// ...
options: {
cssModules: {
// config
}
}
};When importing a CSS module's values from JS, or referencing it via @value or composes:, by default you do not include the .css extension in the import path. The exception to this rule is for modules that are part of an Octane-style colocated component, as the extension is the only thing to differentiate the styles module from the component module itself.
If you wish to enable this behavior for all modules, you can set the includeExtensionInModulePath flag in your configuration:
new EmberApp(defaults, {
cssModules: {
includeExtensionInModulePath: true,
},
});By default, ember-css-modules produces a unique scoped name for each class in a module by combining the original class name with a hash of the path of the containing module. You can override this behavior by passing a generateScopedName function in the configuration.
new EmberApp(defaults, {
cssModules: {
generateScopedName(className, modulePath) {
// Your logic here
}
}
});Note that addons may specify their own generateScopedName function, but otherwise they will fall back to using the one (if any) specified by the host application.
Ember CLI allows you to specify source map settings for your entire build process, and ember-css-modules will honor that configuration. For instance, to enable source maps in all environments for both JS and CSS files, you could put the following in your ember-cli-build.js:
sourcemaps: {
enabled: true,
extensions: ['js', 'css']
}
- You should specify the
cssextension in your source map configuration even if you're using a different extension for your modules themselves, since the final output file will be a.cssfile. - Currently CSS source maps (for any Ember CLI preprocessor) only work for applications, not for addons. Watch ember-cli/broccoli-concat#58 for progress on that front.
- Enabling source maps for CSS can cause Ember CLI to output an invalid comment at the end of your
vendor.cssfile. This is harmless in many situations, but can cause issues with tools that postprocess your css, like ember-cli-autoprefixer. ember-cli/broccoli-concat#58 is the root cause of this issue as well.
This addon is tested against and expected to work with Ember's active LTS releases as well as the current release, beta, and canary builds.