search

salsify / ember-css-modules

CSS Modules for ambitious applications
MIT License
282 stars 49 forks source link

Default import for pod styles #89

Open buschtoens opened 6 years ago

buschtoens commented 6 years ago

When using pod style components it's a bit tedious to always have to append /styles to the import path for @value and composes.

If the given path resolves to a directory, e-c-s should automatically try to load a styles.${defaultExtension} file from it. This way the user can omit /styles.

For instance:

@value header-height as overlap from "auswertung-top/components/data-table/styles";

.header {
  composes: wrapper from "auswertung-top/application/styles";

  padding-bottom: overlap;
}

becomes:

@value header-height as overlap from "auswertung-top/components/data-table";

.header {
  composes: wrapper from "auswertung-top/application";

  padding-bottom: overlap;
}

The only complication I can see is, that resolve-path.js currently does the resolution synchronously without accessing the file system.

dfreeman commented 6 years ago

Hi @buschtoens! That's an interesting idea.

Up to this point, paths used with @value/composes have always worked the same way as import in JS, so for instance if I wanted to extend a component, I'd have to include the /component at the end of the import path.

The general pattern we tend to follow is to basically treat the contents of <component-name>/styles.css as private, and move anything we want to share into more centrally-located modules with descriptive names (e.g. @value grid-padding from 'my-app/styles/layout' or composes: danger from '@salsify/base-styles/buttons')

That said, if we wind up with a solution for #90, wanting to reference things in styles files may become more common... 🤔