honey-css-modules/モチベーション

happy-css-modules のイマイチなところを改善したものを作りたい。要は次世代版 happy-css-modules。

happy-css-modules の問題点

code:src/Button.tsx

import styles from './Button.module.css';

export function Button() {

return <button className={styles.button}>Click me!</button>

}

code:src/Button.tsx

import styles from './components/Button.module.css';

// ...

しかし、現状このように書き換わらない

その逆も然り

3. VS Code の Find all references が期待通りに機能しない

現状できない

エディタ上で非表示にできても、ファイルシステム上には引き続き存在していて、煩わしい

しかし現状オプトインになってる

多くのユーザは煩わしい状態が続いている

5. CSS Variables の export に対応していない

しかし happy-css-modules が出力する型定義ファイルには、CSS Variables が含まれていない

そのため、現状ではそこまで困っているユーザは居ないはず

6. Sass/Less/Postcss によるトランスパイルが辛い

Postcss も plugin で似たようなことができる

export される token を決定するには、一度トランスパイルしないといけない

そのため、happy-css-modules 内部では Sass/Less/Postcss によるトランスパイルを行っている

トランスパイルをした後に、export される token を抽出したり、その token のソースコード上での位置情報を計算してる

token の位置情報の計算がトランスパイル後のコードに対して行われるため、code jump がおかしない挙動になる

本当は7行目だけに jump すべきだけど、10行目も jump 先の候補になってしまっている

https://gyazo.com/3381cbf48b75efc70ab3138087ab8f27

rename 機能を実装する際の足かせになっている

解決策

また、問題4〜7 を解決するために、以下のような設計にしたい。

これで CSS Variables の export に対応できるはず

トランスパイルやめる

Sass/Less もサポートしないことにして、CSS だけサポートする

Parent Selector 的なことは CSS Nesting で代用してもらう

rename 機能を実現するためにも、廃止しておく

細かい設計方針

大方針は決まったので、細かいところを詰めていく。

CSS Modules で定義されている変数構文のこと

そもそも lightningcss がサポートしていない

CSS Variables を代わりに使ってくれという世界観

The @value rule – superseded by standard CSS variables.

CSS Variables では代替できない場面もあるので微妙なところだと思うけど...

lightningcss がサポートしていない以上、実装が難しい

honey-css-modules でもサポートしないことにしたい

Volar.js/TypeScript Language Service Plugin で実装するのだから、生成しなくてもコードジャンプは実現可能なはず

生成しないようにしてみる

code:src/a.module.css

@import './b.module.css';

.a {}

code:src/b.module.css

.b {}

↓

code:dist/a.module.css

.a {}

.b {}

code:dist/a.module.css.d.ts

export default const styles:

& { a: string }

よく使っているのを見かけるけど、実装がかなり大変

ファイルごとに独立して処理するのが難しくなる

どうするか

つまりこう

code:src/a.module.css

@import './b.module.css';

.a {}

code:src/b.module.css

.b {}

↓

code:dist/a.module.css

.a {}

.b {}

code:dist/a.module.css.d.ts

export default const styles:

& { a: string }

思い出せない

code:import-specifiers.module.css

@import './a.module.css';

/* './a.module.css' に resolve される */

@import 'a.module.css';

/*

* Vite で resolve.alias オプションに { '@': './src' } を設定していた場合、

* ./src/a.module.css に resolve される。

*/

@import '@/a.module.css';

/*

* node_modules/bootstrap/package.json に書いてある内容をもとに、

* 解決先が決まる。様々なルールがあるが、bootstrap の場合は

* package.json の style field に書かれている

* node_modules/bootstrap/dist/css/bootstrap.css へと resolve される。

*/

@import '~bootstrap';

結構面倒な処理なので、できれば honey-css-modules 実装したくないが...

happy-css-modules では外部ファイルを @import している場合、生成する型定義ファイルをちょっと変えている

この処理の出し分けをするためにも、resolve はしておいたほうが良いと思う

これを honey-css-modules 向けに実装したい

stylelint/biome 向けに未使用の token を検知する linter rule を用意したい

やったらできるんじゃないか...?

型定義ファイルを生成する部分が形になったら考えたら良い

https://scrapbox.io/files/6733538d80804f6ecd8fbac6.mov

まあ大したことないんじゃないか

この問題を解決すべきか結構悩ましい

依存関係を小さくしたい

enhanced-resolve => oxc-resolver

postcss => lightningcss

Rust で書かない

Rust 使う必要性を感じない

むしろ Volar.js を使うために、JavaScript で書かなければいけない

次はコードのインターフェイスを考える。