css-modules / postcss-modules-extract-imports Goto Github PK

A CSS Modules transform to extract local aliases for inline imports

License: ISC License

JavaScript 53.99% CSS 46.01%

postcss-modules-extract-imports's Introduction

CSS Modules

A CSS Module is a CSS file where all class names and animation names are scoped locally by default. All URLs (url(...)) and @imports are in module request format (./xxx and ../xxx means relative, xxx and xxx/yyy means in modules folder, i.e. in node_modules).

CSS Modules compile to a low-level interchange format called ICSS (or Interoperable CSS) but are written like normal CSS files:

/* style.css */
.className {
  color: green;
}

When importing a CSS Module from a JavaScript Module, it exports an object with all mappings from local names to global names.

import styles from './style.css';

element.innerHTML = '<div class="' + styles.className + '">';

Why CSS Modules?

Local Scope Prevents Clashes: CSS Modules use local scope to avoid style conflicts across different project parts, allowing component-scoped styling.
Clear Style Dependencies: Importing styles into their respective components clarifies which styles impact which areas, enhancing code readability and maintenance.
Solves Global Scope Problems: CSS Modules prevent the common issue of styles in one file affecting the entire project by localizing styles to specific components.
Boosts Reusability and Modularity: CSS Modules allow the same class names in different modules, promoting modular, reusable styling.

postcss-modules-extract-imports's People

Contributors

Stargazers

Watchers

Forkers

douglasduteil npasserini benjie mportuga warmans eecolor

postcss-modules-extract-imports's Issues

topologicalSort.js doesn’t exist in the latest version

Please release a new version of the package. There is no topologicalSort.js file in the current one.

Please add license file

ISC requires a license file.

Support PostCSS 5.x API

This will require a major version bump, as it will affect users on the 4.x path using any 4.x plugins.

No error when composing non-existing selector

Ref: webpack-contrib/css-loader#326

composes order

Just wanted to add the issue as a reminder of the unpleasant use case.

In case there is a selector with a multiple composes rules and another preceding one, which contains the same composes rules, but in the another order, it may result in the confusing order of the resulting css.

For example:

.localA {
  composes: D from './d.css';
}

.localB
{
  composes: F from './f.css';
  composes: D from './d.css'; /* should come after f.css */
}

transforms into

:import("./d.css") {
  i__imported_D_0: D
}

:import("./f.css") {
  i__imported_F_1: F
}

...

:export {
  localA: _source_localA i__imported_D_0;
  localB: _source_localB i__imported_F_1 i__imported_D_0
}

which means, that the contents of the d.css will be loader before f.css.
That may lead to a small collapse for the .localB selector in case F and D contain similar rules.

Relates to css-modules/css-modules#12

package.json main is looking for lib/index.js

lib/index.js does not exist

can't override the default css

browserify-demo
b.css
.b{
color: black
}

.a{
composes: b from 'b.css';
color:red;
}

result: black

:external proposal

I decided to make a separate issue about :external keyword proposal (css-modules/css-modules#147) in order to summarize and discuss the implementation details.

Syntax

In my opinion the :external keyword can be ~~easily~~ implemented with the icss imports which are mostly generated with the current module. So, it will be easy to integrate it into the existing tools.

The possible transformation:

:external(inner from './elsewhere.css') {
  prop: value;
}

into:

:import("./elsewhere.css") {
  _generid_id: inner;
}

._generid_id { /* not sure about the _generid_id pointer */
  prop: value;
}

The next step will be to patch the :import resolving libs in order to check the rules and replace it with imported token. For the parsing convenience the generated rule may be wrapped with any keyword, like :external(_generid_id). So it will transform:

:external(inner from './elsewhere.css') {
  prop: value;
}

into:

:import("./elsewhere.css") {
  _generid_id: inner;
}

:external(._generid_id) {
  prop: value;
}

css-loader

probably should replace :external() things somewhere here: https://github.com/webpack-contrib/css-loader/blob/master/lib/processCss.js#L61-L79

Configure base path for imports.

It'd be nice to leverage a lot of the configuration from https://github.com/postcss/postcss-import and apply it here.

Specifically, I'd like to say composes: white from 'common/css/color.css' instead of composes: white from '../../common/css/color.css'

Don’t use parent#push

According PostCSS docs, Container#push is low level method and should not be used by plugins.

This method is for parsers only. It doesn’t contains checks as result it is easy to broke AST by putting wrong nodes.

This line produces broken AST, because it doesn’t set a parent property.

@geelen You should replace push() to append().

Here is a issue because of this bug: cssnano/cssnano#163 (comment)