Support single file styles

[taishinaritomi]

Support single file styles

[taishinaritomi]

I think this is a very wonderful approach.
I will verify it tomorrow.

[taishinaritomi]

Idea

[Zn4rK]

I think I understand.

You want to collect all identifiers that are using call expressions to style and globalStyle, make them exported, and then import them in the extraction process, instead of just evaluating the user source file like it's done today.

That's smart - and as long as we don't have to emit new file, it should work I think!

[Zn4rK]

Just thinking out loud, but the transform plugin could import a class from "@kaze-style/core" and add an export declaration;

// @kaze-style/core
export class Collector {
  constructor(public calls: any[]) {}
}

// In source file after transform
import { __style, __globalStyle, Collector } from '@kaze-style/core';
const c = __style({});
const $1 = __globalStyle({});

// Can be named anything
export const collector = new Collector([c, $1]);

// In run.ts that's being evaluated, and only collects the stuff we're interested in:
import { Collector } from '@kaze-style/core';
import * as everything from './user-file.ts';

// Pseudo code - but we can use find, since we should only have one Collector
const found = Object.values(everything).find((value) => value instanceof Collector);

if (found) {
 // Collect css
 found.calls.map((x) => x);
}

Collector should be considered dead code in the users code, and not be a part of the finished bundle, since run.ts would be eval()-ed to collect the css.

[taishinaritomi]

I thought of a simple way to do this.
I have only checked with esbuild, but tree shaking also works.

// @kaze-style/core
export const styleCollector = (...x:unknown[]) => x;

// pre-transform './user-file.ts'
import { __preStyle, __preGlobalStyle, styleCollector } from '@kaze-style/core';

const classes = __preStyle({});
const __globalStyle1 = __preGlobalStyle({});

export const __style_collector = styleCollector(classes, __globalStyle1);

// run.ts
import { __style_collector } from './user-file';

((x) => x)(__style_collector);

[Zn4rK]

That will probably work for all the bundlers. The reason I suggested a class is that the name we are giving the new export could in theory be occupied by user code. Then the plugins would have to create a new name, and it would be hard to communicate it back from the plugin to the style extraction and run.ts.

[taishinaritomi]

I tried to verify the Class syntax, but I could not tree shaking and everything was bundled.
If tree shaking is not possible, it will evaluate unnecessary code.

Is there a solution to resolve both?

[Zn4rK]

Hmm, I can't think of a way right now. I'll have to do some experiments of my own. But instead of giving the style_collector a pre-determined name, we could just generate a safe name in js, and send it as arguments to the transformer.

[taishinaritomi]

Currently, we have the same problem with __forBuildByKazeStyle passed as the second argument of __preStyle,__preGlobalStyle in pre-transform.