@tenphi/tasty 0.0.0-snapshot.002b1b3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/README.md +637 -0
- package/dist/async-storage-B7_o6FKt.js +44 -0
- package/dist/async-storage-B7_o6FKt.js.map +1 -0
- package/dist/collector-LuU1vZ68.d.ts +98 -0
- package/dist/collector-MOYY2SOr.js +230 -0
- package/dist/collector-MOYY2SOr.js.map +1 -0
- package/dist/config-A237aY9H.js +10235 -0
- package/dist/config-A237aY9H.js.map +1 -0
- package/dist/config-vuCRkBWX.d.ts +884 -0
- package/dist/context-CkSg-kDT.js +24 -0
- package/dist/context-CkSg-kDT.js.map +1 -0
- package/dist/core/index.d.ts +5 -0
- package/dist/core/index.js +6 -0
- package/dist/core-BkKav78f.js +1592 -0
- package/dist/core-BkKav78f.js.map +1 -0
- package/dist/css-writer-Cos9tQRM.js +329 -0
- package/dist/css-writer-Cos9tQRM.js.map +1 -0
- package/dist/format-global-rules-Dbc_1tc3.js +22 -0
- package/dist/format-global-rules-Dbc_1tc3.js.map +1 -0
- package/dist/format-rules-C2oiTsEO.js +143 -0
- package/dist/format-rules-C2oiTsEO.js.map +1 -0
- package/dist/hydrate-miFzWIKR.js +45 -0
- package/dist/hydrate-miFzWIKR.js.map +1 -0
- package/dist/index-CJMXAAO5.d.ts +1602 -0
- package/dist/index-dUtwpOux.d.ts +1266 -0
- package/dist/index.d.ts +5 -0
- package/dist/index.js +732 -0
- package/dist/index.js.map +1 -0
- package/dist/keyframes-DDtNo_hl.js +587 -0
- package/dist/keyframes-DDtNo_hl.js.map +1 -0
- package/dist/merge-styles-CtDJMhpJ.d.ts +7 -0
- package/dist/merge-styles-D_HbBOlq.js +144 -0
- package/dist/merge-styles-D_HbBOlq.js.map +1 -0
- package/dist/resolve-recipes-B7-823LL.js +144 -0
- package/dist/resolve-recipes-B7-823LL.js.map +1 -0
- package/dist/ssr/astro-client.d.ts +1 -0
- package/dist/ssr/astro-client.js +19 -0
- package/dist/ssr/astro-client.js.map +1 -0
- package/dist/ssr/astro-middleware.d.ts +15 -0
- package/dist/ssr/astro-middleware.js +19 -0
- package/dist/ssr/astro-middleware.js.map +1 -0
- package/dist/ssr/astro.d.ts +97 -0
- package/dist/ssr/astro.js +149 -0
- package/dist/ssr/astro.js.map +1 -0
- package/dist/ssr/index.d.ts +44 -0
- package/dist/ssr/index.js +10 -0
- package/dist/ssr/index.js.map +1 -0
- package/dist/ssr/next.d.ts +46 -0
- package/dist/ssr/next.js +75 -0
- package/dist/ssr/next.js.map +1 -0
- package/dist/static/index.d.ts +91 -0
- package/dist/static/index.js +50 -0
- package/dist/static/index.js.map +1 -0
- package/dist/static/inject.d.ts +5 -0
- package/dist/static/inject.js +17 -0
- package/dist/static/inject.js.map +1 -0
- package/dist/zero/babel.d.ts +81 -0
- package/dist/zero/babel.js +466 -0
- package/dist/zero/babel.js.map +1 -0
- package/dist/zero/index.d.ts +67 -0
- package/dist/zero/index.js +2 -0
- package/dist/zero/next.d.ts +86 -0
- package/dist/zero/next.js +143 -0
- package/dist/zero/next.js.map +1 -0
- package/docs/README.md +31 -0
- package/docs/adoption.md +298 -0
- package/docs/comparison.md +419 -0
- package/docs/configuration.md +394 -0
- package/docs/debug.md +320 -0
- package/docs/design-system.md +436 -0
- package/docs/dsl.md +688 -0
- package/docs/getting-started.md +217 -0
- package/docs/injector.md +544 -0
- package/docs/methodology.md +616 -0
- package/docs/pipeline.md +673 -0
- package/docs/react-api.md +557 -0
- package/docs/ssr.md +442 -0
- package/docs/styles.md +596 -0
- package/docs/tasty-static.md +532 -0
- package/package.json +222 -0
- package/tasty.config.ts +15 -0
|
@@ -0,0 +1,86 @@
|
|
|
1
|
+
import { TastyZeroConfig } from "./babel.js";
|
|
2
|
+
|
|
3
|
+
//#region src/zero/next.d.ts
|
|
4
|
+
interface WebpackConfigContext {
|
|
5
|
+
isServer: boolean;
|
|
6
|
+
dev: boolean;
|
|
7
|
+
buildId: string;
|
|
8
|
+
dir: string;
|
|
9
|
+
}
|
|
10
|
+
interface TurbopackLoaderItem {
|
|
11
|
+
loader: string;
|
|
12
|
+
options?: Record<string, unknown>;
|
|
13
|
+
}
|
|
14
|
+
interface TurbopackRuleConfig {
|
|
15
|
+
loaders: (string | TurbopackLoaderItem)[];
|
|
16
|
+
as?: string;
|
|
17
|
+
condition?: unknown;
|
|
18
|
+
}
|
|
19
|
+
interface TurbopackConfig {
|
|
20
|
+
rules?: Record<string, TurbopackRuleConfig | TurbopackRuleConfig[]>;
|
|
21
|
+
[key: string]: unknown;
|
|
22
|
+
}
|
|
23
|
+
interface NextConfig {
|
|
24
|
+
webpack?: (config: any, context: WebpackConfigContext) => any;
|
|
25
|
+
turbopack?: TurbopackConfig;
|
|
26
|
+
[key: string]: unknown;
|
|
27
|
+
}
|
|
28
|
+
interface TastyZeroNextOptions {
|
|
29
|
+
/**
|
|
30
|
+
* Output path for CSS relative to project root.
|
|
31
|
+
* @default 'public/tasty.css'
|
|
32
|
+
*/
|
|
33
|
+
output?: string;
|
|
34
|
+
/**
|
|
35
|
+
* Whether to enable the plugin.
|
|
36
|
+
* @default true
|
|
37
|
+
*/
|
|
38
|
+
enabled?: boolean;
|
|
39
|
+
/**
|
|
40
|
+
* Tasty configuration for build-time processing.
|
|
41
|
+
* For static configs that don't change during dev.
|
|
42
|
+
*
|
|
43
|
+
* For configs that depend on theme files, use `configFile` instead.
|
|
44
|
+
*/
|
|
45
|
+
config?: TastyZeroConfig;
|
|
46
|
+
/**
|
|
47
|
+
* Path to a TypeScript/JavaScript module that exports the tasty zero config
|
|
48
|
+
* as its default export. The module is re-evaluated on each
|
|
49
|
+
* compilation, enabling hot reload when the file (or its imports) change.
|
|
50
|
+
*
|
|
51
|
+
* @example './app/tasty-zero.config.ts'
|
|
52
|
+
*/
|
|
53
|
+
configFile?: string;
|
|
54
|
+
/**
|
|
55
|
+
* Extra file paths (relative to project root) that the config depends on.
|
|
56
|
+
* When any of these files change, the Babel cache is invalidated and
|
|
57
|
+
* the config is re-evaluated.
|
|
58
|
+
*
|
|
59
|
+
* The `configFile` itself is always tracked automatically.
|
|
60
|
+
* Use this for transitive dependencies that aren't directly imported
|
|
61
|
+
* by the config file, or when using `config` instead of `configFile`.
|
|
62
|
+
*
|
|
63
|
+
* @example ['./app/theme.ts']
|
|
64
|
+
*/
|
|
65
|
+
configDeps?: string[];
|
|
66
|
+
/**
|
|
67
|
+
* Output mode for extracted CSS.
|
|
68
|
+
*
|
|
69
|
+
* - `'file'` (default): CSS is written to a single output file.
|
|
70
|
+
* - `'inject'`: CSS is embedded inline in JS and injected at runtime.
|
|
71
|
+
* No CSS file is written. Best for reusable components and extensions.
|
|
72
|
+
*
|
|
73
|
+
* When `mode` is `'inject'`, `output` is ignored.
|
|
74
|
+
*
|
|
75
|
+
* @default 'file'
|
|
76
|
+
*/
|
|
77
|
+
mode?: 'file' | 'inject';
|
|
78
|
+
}
|
|
79
|
+
/**
|
|
80
|
+
* Next.js configuration wrapper for tasty-zero.
|
|
81
|
+
* Configures both webpack and Turbopack bundlers automatically.
|
|
82
|
+
*/
|
|
83
|
+
declare function withTastyZero(options?: TastyZeroNextOptions): (nextConfig?: NextConfig) => NextConfig;
|
|
84
|
+
//#endregion
|
|
85
|
+
export { TastyZeroNextOptions, withTastyZero };
|
|
86
|
+
//# sourceMappingURL=next.d.ts.map
|
|
@@ -0,0 +1,143 @@
|
|
|
1
|
+
import * as path from "path";
|
|
2
|
+
import { createJiti } from "jiti";
|
|
3
|
+
import { createRequire } from "module";
|
|
4
|
+
import { fileURLToPath } from "url";
|
|
5
|
+
//#region src/zero/next.ts
|
|
6
|
+
/**
|
|
7
|
+
* Next.js configuration wrapper for tasty-zero.
|
|
8
|
+
*
|
|
9
|
+
* Supports both webpack and Turbopack bundlers:
|
|
10
|
+
* - **webpack**: Injects a babel-loader rule with the tasty-zero Babel plugin
|
|
11
|
+
* via `webpack()` config hook. Config is passed as a jiti factory function.
|
|
12
|
+
* - **Turbopack**: Adds a `turbopack.rules` entry with babel-loader and
|
|
13
|
+
* JSON-serializable options (`configFile` path instead of a function).
|
|
14
|
+
* The Babel plugin loads the config internally via jiti.
|
|
15
|
+
*
|
|
16
|
+
* The generated CSS is injected automatically — `@tenphi/tasty/static`
|
|
17
|
+
* imports are replaced with an import of the output CSS file at build time.
|
|
18
|
+
* No manual CSS import in layout files is needed.
|
|
19
|
+
*
|
|
20
|
+
* @example
|
|
21
|
+
* ```javascript
|
|
22
|
+
* // next.config.js
|
|
23
|
+
* const { withTastyZero } = require('@tenphi/tasty/next');
|
|
24
|
+
*
|
|
25
|
+
* module.exports = withTastyZero({
|
|
26
|
+
* output: 'public/tasty.css',
|
|
27
|
+
* configFile: './app/tasty-zero.config.ts',
|
|
28
|
+
* })({
|
|
29
|
+
* // your Next.js config
|
|
30
|
+
* });
|
|
31
|
+
* ```
|
|
32
|
+
*/
|
|
33
|
+
const __filename = fileURLToPath(import.meta.url);
|
|
34
|
+
const __dirname = path.dirname(__filename);
|
|
35
|
+
/**
|
|
36
|
+
* Next.js configuration wrapper for tasty-zero.
|
|
37
|
+
* Configures both webpack and Turbopack bundlers automatically.
|
|
38
|
+
*/
|
|
39
|
+
function withTastyZero(options = {}) {
|
|
40
|
+
const { output = "public/tasty.css", enabled = true, config: tastyConfig, configFile, configDeps = [], mode } = options;
|
|
41
|
+
return (nextConfig = {}) => {
|
|
42
|
+
if (!enabled) return nextConfig;
|
|
43
|
+
const projectDir = process.cwd();
|
|
44
|
+
const absoluteOutput = path.resolve(projectDir, output);
|
|
45
|
+
const babelPluginPath = path.resolve(__dirname, "babel.js");
|
|
46
|
+
const absoluteConfigFile = configFile ? path.resolve(projectDir, configFile) : void 0;
|
|
47
|
+
const allDeps = [...absoluteConfigFile ? [absoluteConfigFile] : [], ...configDeps.map((dep) => path.resolve(projectDir, dep))];
|
|
48
|
+
const turbopackBabelOptions = {
|
|
49
|
+
babelrc: false,
|
|
50
|
+
configFile: false,
|
|
51
|
+
parserOpts: { plugins: [
|
|
52
|
+
"typescript",
|
|
53
|
+
"jsx",
|
|
54
|
+
"decorators-legacy"
|
|
55
|
+
] },
|
|
56
|
+
plugins: [[babelPluginPath, {
|
|
57
|
+
output: absoluteOutput,
|
|
58
|
+
injectImport: true,
|
|
59
|
+
...mode ? { mode } : {},
|
|
60
|
+
...absoluteConfigFile ? { configFile: absoluteConfigFile } : tastyConfig ? { config: tastyConfig } : {},
|
|
61
|
+
...allDeps.length > 0 ? { configDeps: allDeps } : {}
|
|
62
|
+
}]]
|
|
63
|
+
};
|
|
64
|
+
const existingTurbopack = nextConfig.turbopack || {};
|
|
65
|
+
const existingRules = existingTurbopack.rules || {};
|
|
66
|
+
const existingExperimental = nextConfig.experimental || {};
|
|
67
|
+
return {
|
|
68
|
+
...nextConfig,
|
|
69
|
+
experimental: {
|
|
70
|
+
...existingExperimental,
|
|
71
|
+
turbopackUseBuiltinBabel: true
|
|
72
|
+
},
|
|
73
|
+
turbopack: {
|
|
74
|
+
...existingTurbopack,
|
|
75
|
+
rules: {
|
|
76
|
+
...existingRules,
|
|
77
|
+
"*.{ts,tsx,js,jsx}": {
|
|
78
|
+
condition: { not: "foreign" },
|
|
79
|
+
loaders: [{
|
|
80
|
+
loader: "babel-loader",
|
|
81
|
+
options: turbopackBabelOptions
|
|
82
|
+
}]
|
|
83
|
+
}
|
|
84
|
+
}
|
|
85
|
+
},
|
|
86
|
+
webpack(config, context) {
|
|
87
|
+
const { dir } = context;
|
|
88
|
+
const wpProjectDir = dir || projectDir;
|
|
89
|
+
const wpAbsoluteOutput = path.resolve(wpProjectDir, output);
|
|
90
|
+
const projectRequire = createRequire(path.resolve(wpProjectDir, "package.json"));
|
|
91
|
+
const wpAbsoluteConfigFile = configFile ? path.resolve(wpProjectDir, configFile) : void 0;
|
|
92
|
+
const wpAllDeps = [...wpAbsoluteConfigFile ? [wpAbsoluteConfigFile] : [], ...configDeps.map((dep) => path.resolve(wpProjectDir, dep))];
|
|
93
|
+
const babelPluginOptions = {
|
|
94
|
+
output: wpAbsoluteOutput,
|
|
95
|
+
injectImport: true,
|
|
96
|
+
...mode ? { mode } : {}
|
|
97
|
+
};
|
|
98
|
+
if (wpAbsoluteConfigFile) {
|
|
99
|
+
const jiti = createJiti(wpProjectDir, { moduleCache: false });
|
|
100
|
+
babelPluginOptions.config = () => {
|
|
101
|
+
return jiti(wpAbsoluteConfigFile);
|
|
102
|
+
};
|
|
103
|
+
} else if (tastyConfig) babelPluginOptions.config = tastyConfig;
|
|
104
|
+
if (wpAllDeps.length > 0) babelPluginOptions.configDeps = wpAllDeps;
|
|
105
|
+
const babelPluginConfig = [babelPluginPath, babelPluginOptions];
|
|
106
|
+
const existingRule = config.module?.rules?.find((rule) => rule.use?.loader === "babel-loader" || rule.use?.some?.((u) => u.loader === "babel-loader"));
|
|
107
|
+
if (existingRule) {
|
|
108
|
+
const babelUse = Array.isArray(existingRule.use) ? existingRule.use.find((u) => u.loader === "babel-loader") : existingRule.use;
|
|
109
|
+
if (babelUse?.options) {
|
|
110
|
+
babelUse.options.plugins = babelUse.options.plugins || [];
|
|
111
|
+
babelUse.options.plugins.push(babelPluginConfig);
|
|
112
|
+
}
|
|
113
|
+
} else {
|
|
114
|
+
config.module = config.module || {};
|
|
115
|
+
config.module.rules = config.module.rules || [];
|
|
116
|
+
config.module.rules.push({
|
|
117
|
+
test: /\.(tsx?|jsx?)$/,
|
|
118
|
+
exclude: /node_modules/,
|
|
119
|
+
use: [{
|
|
120
|
+
loader: projectRequire.resolve("babel-loader"),
|
|
121
|
+
options: {
|
|
122
|
+
babelrc: false,
|
|
123
|
+
configFile: false,
|
|
124
|
+
parserOpts: { plugins: [
|
|
125
|
+
"typescript",
|
|
126
|
+
"jsx",
|
|
127
|
+
"decorators-legacy"
|
|
128
|
+
] },
|
|
129
|
+
plugins: [babelPluginConfig]
|
|
130
|
+
}
|
|
131
|
+
}]
|
|
132
|
+
});
|
|
133
|
+
}
|
|
134
|
+
if (typeof nextConfig.webpack === "function") return nextConfig.webpack(config, context);
|
|
135
|
+
return config;
|
|
136
|
+
}
|
|
137
|
+
};
|
|
138
|
+
};
|
|
139
|
+
}
|
|
140
|
+
//#endregion
|
|
141
|
+
export { withTastyZero };
|
|
142
|
+
|
|
143
|
+
//# sourceMappingURL=next.js.map
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
{"version":3,"file":"next.js","names":[],"sources":["../../src/zero/next.ts"],"sourcesContent":["/**\n * Next.js configuration wrapper for tasty-zero.\n *\n * Supports both webpack and Turbopack bundlers:\n * - **webpack**: Injects a babel-loader rule with the tasty-zero Babel plugin\n * via `webpack()` config hook. Config is passed as a jiti factory function.\n * - **Turbopack**: Adds a `turbopack.rules` entry with babel-loader and\n * JSON-serializable options (`configFile` path instead of a function).\n * The Babel plugin loads the config internally via jiti.\n *\n * The generated CSS is injected automatically — `@tenphi/tasty/static`\n * imports are replaced with an import of the output CSS file at build time.\n * No manual CSS import in layout files is needed.\n *\n * @example\n * ```javascript\n * // next.config.js\n * const { withTastyZero } = require('@tenphi/tasty/next');\n *\n * module.exports = withTastyZero({\n * output: 'public/tasty.css',\n * configFile: './app/tasty-zero.config.ts',\n * })({\n * // your Next.js config\n * });\n * ```\n */\n\nimport { createRequire } from 'module';\nimport * as path from 'path';\nimport { fileURLToPath } from 'url';\n\nimport { createJiti } from 'jiti';\n\nimport type { TastyZeroBabelOptions, TastyZeroConfig } from './babel';\n\nconst __filename = fileURLToPath(import.meta.url);\nconst __dirname = path.dirname(__filename);\n\n// Next.js types (inline to avoid requiring next as a dependency)\ninterface WebpackConfigContext {\n isServer: boolean;\n dev: boolean;\n buildId: string;\n dir: string;\n}\n\n/* eslint-disable @typescript-eslint/no-explicit-any -- webpack/Next.js config types are complex */\ninterface TurbopackLoaderItem {\n loader: string;\n options?: Record<string, unknown>;\n}\n\ninterface TurbopackRuleConfig {\n loaders: (string | TurbopackLoaderItem)[];\n as?: string;\n condition?: unknown;\n}\n\ninterface TurbopackConfig {\n rules?: Record<string, TurbopackRuleConfig | TurbopackRuleConfig[]>;\n [key: string]: unknown;\n}\n\ninterface NextConfig {\n webpack?: (config: any, context: WebpackConfigContext) => any;\n turbopack?: TurbopackConfig;\n [key: string]: unknown;\n}\n\nexport interface TastyZeroNextOptions {\n /**\n * Output path for CSS relative to project root.\n * @default 'public/tasty.css'\n */\n output?: string;\n\n /**\n * Whether to enable the plugin.\n * @default true\n */\n enabled?: boolean;\n\n /**\n * Tasty configuration for build-time processing.\n * For static configs that don't change during dev.\n *\n * For configs that depend on theme files, use `configFile` instead.\n */\n config?: TastyZeroConfig;\n\n /**\n * Path to a TypeScript/JavaScript module that exports the tasty zero config\n * as its default export. The module is re-evaluated on each\n * compilation, enabling hot reload when the file (or its imports) change.\n *\n * @example './app/tasty-zero.config.ts'\n */\n configFile?: string;\n\n /**\n * Extra file paths (relative to project root) that the config depends on.\n * When any of these files change, the Babel cache is invalidated and\n * the config is re-evaluated.\n *\n * The `configFile` itself is always tracked automatically.\n * Use this for transitive dependencies that aren't directly imported\n * by the config file, or when using `config` instead of `configFile`.\n *\n * @example ['./app/theme.ts']\n */\n configDeps?: string[];\n\n /**\n * Output mode for extracted CSS.\n *\n * - `'file'` (default): CSS is written to a single output file.\n * - `'inject'`: CSS is embedded inline in JS and injected at runtime.\n * No CSS file is written. Best for reusable components and extensions.\n *\n * When `mode` is `'inject'`, `output` is ignored.\n *\n * @default 'file'\n */\n mode?: 'file' | 'inject';\n}\n\n/**\n * Next.js configuration wrapper for tasty-zero.\n * Configures both webpack and Turbopack bundlers automatically.\n */\nexport function withTastyZero(options: TastyZeroNextOptions = {}) {\n const {\n output = 'public/tasty.css',\n enabled = true,\n config: tastyConfig,\n configFile,\n configDeps = [],\n mode,\n } = options;\n\n return (nextConfig: NextConfig = {}): NextConfig => {\n if (!enabled) {\n return nextConfig;\n }\n\n const projectDir = process.cwd();\n const absoluteOutput = path.resolve(projectDir, output);\n const babelPluginPath = path.resolve(__dirname, 'babel.js');\n\n const absoluteConfigFile = configFile\n ? path.resolve(projectDir, configFile)\n : undefined;\n\n const allDeps = [\n ...(absoluteConfigFile ? [absoluteConfigFile] : []),\n ...configDeps.map((dep) => path.resolve(projectDir, dep)),\n ];\n\n // --- Turbopack configuration ---\n // Turbopack loader options must be JSON-serializable (no functions).\n // The Babel plugin loads config internally via `configFile` path + jiti.\n const turbopackBabelOptions: Record<string, unknown> = {\n babelrc: false,\n configFile: false,\n parserOpts: {\n plugins: ['typescript', 'jsx', 'decorators-legacy'],\n },\n plugins: [\n [\n babelPluginPath,\n {\n output: absoluteOutput,\n injectImport: true,\n ...(mode ? { mode } : {}),\n ...(absoluteConfigFile\n ? { configFile: absoluteConfigFile }\n : tastyConfig\n ? { config: tastyConfig }\n : {}),\n ...(allDeps.length > 0 ? { configDeps: allDeps } : {}),\n },\n ],\n ],\n };\n\n const existingTurbopack = nextConfig.turbopack || {};\n const existingRules = existingTurbopack.rules || {};\n\n const existingExperimental =\n (nextConfig.experimental as Record<string, unknown>) || {};\n\n return {\n ...nextConfig,\n\n experimental: {\n ...existingExperimental,\n turbopackUseBuiltinBabel: true,\n },\n\n turbopack: {\n ...existingTurbopack,\n rules: {\n ...existingRules,\n '*.{ts,tsx,js,jsx}': {\n condition: { not: 'foreign' },\n loaders: [\n {\n loader: 'babel-loader',\n options: turbopackBabelOptions,\n },\n ],\n },\n },\n },\n\n webpack(config: any, context: WebpackConfigContext) {\n const { dir } = context;\n\n const wpProjectDir = dir || projectDir;\n const wpAbsoluteOutput = path.resolve(wpProjectDir, output);\n const projectRequire = createRequire(\n path.resolve(wpProjectDir, 'package.json'),\n );\n\n const wpAbsoluteConfigFile = configFile\n ? path.resolve(wpProjectDir, configFile)\n : undefined;\n\n const wpAllDeps = [\n ...(wpAbsoluteConfigFile ? [wpAbsoluteConfigFile] : []),\n ...configDeps.map((dep) => path.resolve(wpProjectDir, dep)),\n ];\n\n const babelPluginOptions: TastyZeroBabelOptions = {\n output: wpAbsoluteOutput,\n injectImport: true,\n ...(mode ? { mode } : {}),\n };\n\n if (wpAbsoluteConfigFile) {\n const jiti = createJiti(wpProjectDir, {\n moduleCache: false,\n });\n\n babelPluginOptions.config = () => {\n return jiti(wpAbsoluteConfigFile) as TastyZeroConfig;\n };\n } else if (tastyConfig) {\n babelPluginOptions.config = tastyConfig;\n }\n\n if (wpAllDeps.length > 0) {\n babelPluginOptions.configDeps = wpAllDeps;\n }\n\n const babelPluginConfig = [babelPluginPath, babelPluginOptions];\n\n const existingRule = config.module?.rules?.find(\n (rule: any) =>\n rule.use?.loader === 'babel-loader' ||\n rule.use?.some?.((u: any) => u.loader === 'babel-loader'),\n );\n\n if (existingRule) {\n const babelUse = Array.isArray(existingRule.use)\n ? existingRule.use.find((u: any) => u.loader === 'babel-loader')\n : existingRule.use;\n\n if (babelUse?.options) {\n babelUse.options.plugins = babelUse.options.plugins || [];\n babelUse.options.plugins.push(babelPluginConfig);\n }\n } else {\n config.module = config.module || {};\n config.module.rules = config.module.rules || [];\n config.module.rules.push({\n test: /\\.(tsx?|jsx?)$/,\n exclude: /node_modules/,\n use: [\n {\n loader: projectRequire.resolve('babel-loader'),\n options: {\n babelrc: false,\n configFile: false,\n parserOpts: {\n plugins: ['typescript', 'jsx', 'decorators-legacy'],\n },\n plugins: [babelPluginConfig],\n },\n },\n ],\n });\n }\n\n if (typeof nextConfig.webpack === 'function') {\n return nextConfig.webpack(config, context);\n }\n\n return config;\n },\n };\n };\n}\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAoCA,MAAM,aAAa,cAAc,OAAO,KAAK,IAAI;AACjD,MAAM,YAAY,KAAK,QAAQ,WAAW;;;;;AA8F1C,SAAgB,cAAc,UAAgC,EAAE,EAAE;CAChE,MAAM,EACJ,SAAS,oBACT,UAAU,MACV,QAAQ,aACR,YACA,aAAa,EAAE,EACf,SACE;AAEJ,SAAQ,aAAyB,EAAE,KAAiB;AAClD,MAAI,CAAC,QACH,QAAO;EAGT,MAAM,aAAa,QAAQ,KAAK;EAChC,MAAM,iBAAiB,KAAK,QAAQ,YAAY,OAAO;EACvD,MAAM,kBAAkB,KAAK,QAAQ,WAAW,WAAW;EAE3D,MAAM,qBAAqB,aACvB,KAAK,QAAQ,YAAY,WAAW,GACpC,KAAA;EAEJ,MAAM,UAAU,CACd,GAAI,qBAAqB,CAAC,mBAAmB,GAAG,EAAE,EAClD,GAAG,WAAW,KAAK,QAAQ,KAAK,QAAQ,YAAY,IAAI,CAAC,CAC1D;EAKD,MAAM,wBAAiD;GACrD,SAAS;GACT,YAAY;GACZ,YAAY,EACV,SAAS;IAAC;IAAc;IAAO;IAAoB,EACpD;GACD,SAAS,CACP,CACE,iBACA;IACE,QAAQ;IACR,cAAc;IACd,GAAI,OAAO,EAAE,MAAM,GAAG,EAAE;IACxB,GAAI,qBACA,EAAE,YAAY,oBAAoB,GAClC,cACE,EAAE,QAAQ,aAAa,GACvB,EAAE;IACR,GAAI,QAAQ,SAAS,IAAI,EAAE,YAAY,SAAS,GAAG,EAAE;IACtD,CACF,CACF;GACF;EAED,MAAM,oBAAoB,WAAW,aAAa,EAAE;EACpD,MAAM,gBAAgB,kBAAkB,SAAS,EAAE;EAEnD,MAAM,uBACH,WAAW,gBAA4C,EAAE;AAE5D,SAAO;GACL,GAAG;GAEH,cAAc;IACZ,GAAG;IACH,0BAA0B;IAC3B;GAED,WAAW;IACT,GAAG;IACH,OAAO;KACL,GAAG;KACH,qBAAqB;MACnB,WAAW,EAAE,KAAK,WAAW;MAC7B,SAAS,CACP;OACE,QAAQ;OACR,SAAS;OACV,CACF;MACF;KACF;IACF;GAED,QAAQ,QAAa,SAA+B;IAClD,MAAM,EAAE,QAAQ;IAEhB,MAAM,eAAe,OAAO;IAC5B,MAAM,mBAAmB,KAAK,QAAQ,cAAc,OAAO;IAC3D,MAAM,iBAAiB,cACrB,KAAK,QAAQ,cAAc,eAAe,CAC3C;IAED,MAAM,uBAAuB,aACzB,KAAK,QAAQ,cAAc,WAAW,GACtC,KAAA;IAEJ,MAAM,YAAY,CAChB,GAAI,uBAAuB,CAAC,qBAAqB,GAAG,EAAE,EACtD,GAAG,WAAW,KAAK,QAAQ,KAAK,QAAQ,cAAc,IAAI,CAAC,CAC5D;IAED,MAAM,qBAA4C;KAChD,QAAQ;KACR,cAAc;KACd,GAAI,OAAO,EAAE,MAAM,GAAG,EAAE;KACzB;AAED,QAAI,sBAAsB;KACxB,MAAM,OAAO,WAAW,cAAc,EACpC,aAAa,OACd,CAAC;AAEF,wBAAmB,eAAe;AAChC,aAAO,KAAK,qBAAqB;;eAE1B,YACT,oBAAmB,SAAS;AAG9B,QAAI,UAAU,SAAS,EACrB,oBAAmB,aAAa;IAGlC,MAAM,oBAAoB,CAAC,iBAAiB,mBAAmB;IAE/D,MAAM,eAAe,OAAO,QAAQ,OAAO,MACxC,SACC,KAAK,KAAK,WAAW,kBACrB,KAAK,KAAK,QAAQ,MAAW,EAAE,WAAW,eAAe,CAC5D;AAED,QAAI,cAAc;KAChB,MAAM,WAAW,MAAM,QAAQ,aAAa,IAAI,GAC5C,aAAa,IAAI,MAAM,MAAW,EAAE,WAAW,eAAe,GAC9D,aAAa;AAEjB,SAAI,UAAU,SAAS;AACrB,eAAS,QAAQ,UAAU,SAAS,QAAQ,WAAW,EAAE;AACzD,eAAS,QAAQ,QAAQ,KAAK,kBAAkB;;WAE7C;AACL,YAAO,SAAS,OAAO,UAAU,EAAE;AACnC,YAAO,OAAO,QAAQ,OAAO,OAAO,SAAS,EAAE;AAC/C,YAAO,OAAO,MAAM,KAAK;MACvB,MAAM;MACN,SAAS;MACT,KAAK,CACH;OACE,QAAQ,eAAe,QAAQ,eAAe;OAC9C,SAAS;QACP,SAAS;QACT,YAAY;QACZ,YAAY,EACV,SAAS;SAAC;SAAc;SAAO;SAAoB,EACpD;QACD,SAAS,CAAC,kBAAkB;QAC7B;OACF,CACF;MACF,CAAC;;AAGJ,QAAI,OAAO,WAAW,YAAY,WAChC,QAAO,WAAW,QAAQ,QAAQ,QAAQ;AAG5C,WAAO;;GAEV"}
|
package/docs/README.md
ADDED
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
# Tasty Docs
|
|
2
|
+
|
|
3
|
+
Tasty is a styling engine for design systems that turns component state into deterministic CSS by compiling state maps into mutually exclusive selectors. Use this hub to choose the right guide once you know whether you are evaluating the model, adopting it in a design system, or implementing reusable, stateful components day to day.
|
|
4
|
+
|
|
5
|
+
## Start Here
|
|
6
|
+
|
|
7
|
+
- **New to Tasty**: [Getting Started](getting-started.md) for installation, the first component, optional shared `configure()`, ESLint, editor tooling, and rendering mode selection.
|
|
8
|
+
- **Learning the component model**: [Methodology](methodology.md) for root + sub-elements, `styleProps`, tokens, extension, and recommended boundaries between `styles`, `style`, and wrappers.
|
|
9
|
+
- **Evaluating the selector model**: [Style rendering pipeline](pipeline.md) for how mutually exclusive selectors make stateful styling deterministic.
|
|
10
|
+
- **Evaluating fit**: [Comparison](comparison.md) for tool-selection context, then [Adoption Guide](adoption.md) for audience fit and rollout strategy inside a design system.
|
|
11
|
+
|
|
12
|
+
## By Role
|
|
13
|
+
|
|
14
|
+
- **Application developer using an existing design system**: [Getting Started](getting-started.md), then [React API](react-api.md).
|
|
15
|
+
- **Design-system author**: [Methodology](methodology.md), [Building a Design System](design-system.md), [Configuration](configuration.md), and [Adoption Guide](adoption.md).
|
|
16
|
+
- **Platform or tooling engineer**: [Configuration](configuration.md), [Zero Runtime (tastyStatic)](tasty-static.md), [Server-Side Rendering](ssr.md), and [Debug Utilities](debug.md).
|
|
17
|
+
|
|
18
|
+
## By Styling Approach
|
|
19
|
+
|
|
20
|
+
- **React components**: [React API](react-api.md)
|
|
21
|
+
- **Zero-runtime / build-time extraction**: [Zero Runtime (tastyStatic)](tasty-static.md)
|
|
22
|
+
- **Runtime `tasty()` with server collection and hydration**: [Server-Side Rendering](ssr.md)
|
|
23
|
+
|
|
24
|
+
## By Task
|
|
25
|
+
|
|
26
|
+
- **Learn the style language**: [Style DSL](dsl.md)
|
|
27
|
+
- **Look up a property handler**: [Style Properties](styles.md)
|
|
28
|
+
- **Define tokens, units, recipes, keyframes, or properties globally**: [Configuration](configuration.md)
|
|
29
|
+
- **Debug generated CSS or cache behavior**: [Debug Utilities](debug.md)
|
|
30
|
+
- **Understand how selector generation works internally**: [Style rendering pipeline](pipeline.md)
|
|
31
|
+
- **Understand runtime injection internals**: [Style Injector](injector.md)
|
package/docs/adoption.md
ADDED
|
@@ -0,0 +1,298 @@
|
|
|
1
|
+
# Adoption Guide
|
|
2
|
+
|
|
3
|
+
Tasty is not a drop-in replacement for another styling library. It is a **substrate for building a design-system-defined styling language**: what the comparison guide calls a house styling language. That means adoption usually starts where styling for reusable, stateful components has already become a composition problem, not with an all-at-once rewrite.
|
|
4
|
+
|
|
5
|
+
This guide is for design-system maintainers and platform engineers evaluating Tasty or introducing it into an existing codebase. Use this document for rollout strategy and adoption sequencing; use the [Comparison guide](comparison.md) when the open question is whether Tasty is the right tool in the first place.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Where Tasty sits in the stack
|
|
10
|
+
|
|
11
|
+
Tasty is not the surface your product engineers interact with directly. It sits one layer below:
|
|
12
|
+
|
|
13
|
+
```
|
|
14
|
+
Product code
|
|
15
|
+
└─ DS components (Button, Card, Layout, ...)
|
|
16
|
+
└─ Tasty engine (tasty(), configure(), style functions)
|
|
17
|
+
└─ CSS (mutually exclusive selectors, tokens, custom properties)
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
**What Tasty owns:**
|
|
21
|
+
- The DSL and value parser (tokens, custom units, auto-calc, color opacity)
|
|
22
|
+
- State compilation (mutually exclusive selectors from state maps)
|
|
23
|
+
- Style injection and deduplication (runtime or build-time)
|
|
24
|
+
- The `tasty()` component factory and hooks API
|
|
25
|
+
|
|
26
|
+
**What the DS team owns:**
|
|
27
|
+
- Token names and values (colors, spacing, typography)
|
|
28
|
+
- Custom units and their semantics
|
|
29
|
+
- State aliases (`@mobile`, `@dark`, `@compact`)
|
|
30
|
+
- Recipes (reusable style bundles)
|
|
31
|
+
- Which style props each component exposes
|
|
32
|
+
- Sub-element structure for compound components
|
|
33
|
+
- The override and extension rules product teams follow
|
|
34
|
+
|
|
35
|
+
Two teams using Tasty can end up with very different authoring models. That is by design.
|
|
36
|
+
|
|
37
|
+
---
|
|
38
|
+
|
|
39
|
+
## Who should adopt Tasty
|
|
40
|
+
|
|
41
|
+
**Strong fit:**
|
|
42
|
+
- A design-system or platform team that wants to define a governed styling language
|
|
43
|
+
- Components with complex, intersecting states (hover + disabled + theme + breakpoint)
|
|
44
|
+
- Teams that need deterministic style resolution without cascade/specificity bugs
|
|
45
|
+
- Organizations where styling decisions should be centralized, not distributed
|
|
46
|
+
|
|
47
|
+
**Not the right fit:**
|
|
48
|
+
- Solo developers building a one-off app with minimal UI structure
|
|
49
|
+
- Teams that want a shared utility vocabulary and direct markup authoring (Tailwind is better here)
|
|
50
|
+
- Projects where low ceremony matters more than central governance
|
|
51
|
+
- Codebases where intersecting state complexity is low
|
|
52
|
+
|
|
53
|
+
For a detailed comparison with Tailwind, Panda CSS, vanilla-extract, StyleX, Stitches, and Emotion, see the [Comparison guide](comparison.md).
|
|
54
|
+
|
|
55
|
+
---
|
|
56
|
+
|
|
57
|
+
## What you are expected to define
|
|
58
|
+
|
|
59
|
+
Tasty provides the engine. The DS team defines the language that runs on it. Here is what that typically involves:
|
|
60
|
+
|
|
61
|
+
| Layer | What you define | Where |
|
|
62
|
+
|-------|----------------|-------|
|
|
63
|
+
| **Tokens** | Color names, spacing scale, border widths, radii | `configure({ tokens })` |
|
|
64
|
+
| **Units** | Custom multiplier units (`x`, `r`, `bw`, or your own) | `configure({ units })` |
|
|
65
|
+
| **State aliases** | Responsive breakpoints, theme modes, feature flags | `configure({ states })` |
|
|
66
|
+
| **Recipes** | Reusable style bundles (card, elevated, input-reset) | `configure({ recipes })` |
|
|
67
|
+
| **Typography** | Preset definitions (h1-h6, t1-t4, etc.) | `configure({ presets: { ... } })` |
|
|
68
|
+
| **Style props** | Which CSS properties each component exposes as React props | `styleProps` in each component |
|
|
69
|
+
| **Sub-elements** | Inner parts of compound components (Title, Icon, Content) | `elements` + capitalized keys in `styles` |
|
|
70
|
+
| **Override rules** | How product engineers extend or constrain components | Styled wrappers via `tasty(Base, { ... })` |
|
|
71
|
+
|
|
72
|
+
The same engine can power a minimal design system with a handful of tokens:
|
|
73
|
+
|
|
74
|
+
```tsx
|
|
75
|
+
configure({
|
|
76
|
+
tokens: { '#bg': '#white', '#text': '#111' },
|
|
77
|
+
states: { '@dark': '@root(schema=dark)' },
|
|
78
|
+
});
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
...or an enterprise-scale system with dozens of tokens, multiple state aliases, typography presets, recipes, and custom units. The scope is yours to decide.
|
|
82
|
+
|
|
83
|
+
Here is how the layers connect end-to-end. The DS team configures the engine, defines components, and product engineers consume them:
|
|
84
|
+
|
|
85
|
+
```tsx
|
|
86
|
+
// ds/config.ts — DS team defines the language
|
|
87
|
+
configure({
|
|
88
|
+
tokens: { '#primary': 'oklch(55% 0.25 265)', '#surface': '#fff', '#text': '#111' },
|
|
89
|
+
states: { '@mobile': '@media(w < 768px)', '@dark': '@root(schema=dark)' },
|
|
90
|
+
recipes: { card: { padding: '4x', fill: '#surface', radius: '1r', border: true } },
|
|
91
|
+
});
|
|
92
|
+
|
|
93
|
+
// ds/components/Card.tsx — DS team builds components on top
|
|
94
|
+
const Card = tasty({
|
|
95
|
+
styles: {
|
|
96
|
+
recipe: 'card',
|
|
97
|
+
Title: { preset: 'h3', color: '#primary' },
|
|
98
|
+
Body: { preset: 't2', color: '#text' },
|
|
99
|
+
},
|
|
100
|
+
elements: { Title: 'h2', Body: 'div' },
|
|
101
|
+
styleProps: ['padding', 'fill'],
|
|
102
|
+
});
|
|
103
|
+
|
|
104
|
+
// app/Dashboard.tsx — product engineer uses the component
|
|
105
|
+
<Card padding={{ '': '4x', '@mobile': '2x' }}>
|
|
106
|
+
<Card.Title>Monthly Revenue</Card.Title>
|
|
107
|
+
<Card.Body>$1.2M — up 12% from last month</Card.Body>
|
|
108
|
+
</Card>
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
See [Configuration](configuration.md) for the full `configure()` API.
|
|
112
|
+
|
|
113
|
+
---
|
|
114
|
+
|
|
115
|
+
## Incremental adoption
|
|
116
|
+
|
|
117
|
+
You do not need to adopt everything at once. Tasty is designed to be introduced layer by layer.
|
|
118
|
+
|
|
119
|
+
A practical way to start is with the components that already suffer from intersecting state and variant logic: buttons, inputs, menus, disclosures, dialogs, list items, interactive cards, and compound components. Those are the places where deterministic resolution pays off fastest.
|
|
120
|
+
|
|
121
|
+
### Phase 1 -- Tokens and units
|
|
122
|
+
|
|
123
|
+
Start by defining your design tokens and custom units. This is the lowest-risk step: it only configures the parser and does not require rewriting any components.
|
|
124
|
+
|
|
125
|
+
```tsx
|
|
126
|
+
import { configure } from '@tenphi/tasty';
|
|
127
|
+
|
|
128
|
+
configure({
|
|
129
|
+
tokens: {
|
|
130
|
+
'#primary': 'oklch(55% 0.25 265)',
|
|
131
|
+
'#surface': '#white',
|
|
132
|
+
'#text': '#111',
|
|
133
|
+
'$card-padding': '4x',
|
|
134
|
+
},
|
|
135
|
+
// Common units (x, r, bw, ow, cr) are built-in.
|
|
136
|
+
// A DS typically redefines them to use CSS custom properties
|
|
137
|
+
// so that the actual scale is controlled via CSS, not JS:
|
|
138
|
+
units: {
|
|
139
|
+
x: 'var(--gap)', // 2x → calc(var(--gap) * 2)
|
|
140
|
+
r: 'var(--radius)',
|
|
141
|
+
bw: 'var(--border-width)',
|
|
142
|
+
},
|
|
143
|
+
});
|
|
144
|
+
```
|
|
145
|
+
|
|
146
|
+
### Phase 2 -- State aliases and recipes
|
|
147
|
+
|
|
148
|
+
Define the state vocabulary your components will share. This is where you start encoding your team's conventions.
|
|
149
|
+
|
|
150
|
+
```tsx
|
|
151
|
+
configure({
|
|
152
|
+
states: {
|
|
153
|
+
'@mobile': '@media(w < 768px)',
|
|
154
|
+
'@tablet': '@media(w < 1024px)',
|
|
155
|
+
'@dark': '@root(schema=dark) | (!@root(schema) & @media(prefers-color-scheme: dark))',
|
|
156
|
+
},
|
|
157
|
+
recipes: {
|
|
158
|
+
card: { padding: '4x', fill: '#surface', radius: '1r', border: true },
|
|
159
|
+
elevated: { shadow: '0 2x 4x #shadow' },
|
|
160
|
+
},
|
|
161
|
+
});
|
|
162
|
+
```
|
|
163
|
+
|
|
164
|
+
### Phase 3 -- Migrate a few primitives
|
|
165
|
+
|
|
166
|
+
Pick 2-3 widely used primitives (Box, Text, Button) and rewrite them with `tasty()`. Keep the public API identical so product code does not need to change.
|
|
167
|
+
|
|
168
|
+
```tsx
|
|
169
|
+
const Box = tasty({
|
|
170
|
+
as: 'div',
|
|
171
|
+
styles: {
|
|
172
|
+
display: 'flex',
|
|
173
|
+
flow: 'column',
|
|
174
|
+
gap: '1x',
|
|
175
|
+
},
|
|
176
|
+
styleProps: ['gap', 'flow', 'padding', 'fill'],
|
|
177
|
+
});
|
|
178
|
+
```
|
|
179
|
+
|
|
180
|
+
At this point you can validate the DSL, token workflow, and component authoring experience before expanding the rollout.
|
|
181
|
+
|
|
182
|
+
### Phase 4 -- Encode complex states
|
|
183
|
+
|
|
184
|
+
Move the components with the most painful intersecting states (buttons with hover + disabled + theme variants, inputs with focus + error + readonly) to Tasty's state map syntax. This is where mutually exclusive selectors start paying off.
|
|
185
|
+
|
|
186
|
+
```tsx
|
|
187
|
+
const Button = tasty({
|
|
188
|
+
as: 'button',
|
|
189
|
+
styles: {
|
|
190
|
+
fill: {
|
|
191
|
+
'': '#primary',
|
|
192
|
+
':hover': '#primary-hover',
|
|
193
|
+
':active': '#primary-pressed',
|
|
194
|
+
// `disabled` is a data-attribute modifier → [data-disabled].
|
|
195
|
+
// Tasty auto-applies it from the native `disabled` attribute.
|
|
196
|
+
// `[disabled]` (attribute selector) also works here.
|
|
197
|
+
disabled: '#surface',
|
|
198
|
+
},
|
|
199
|
+
color: {
|
|
200
|
+
'': '#on-primary',
|
|
201
|
+
disabled: '#text.40',
|
|
202
|
+
},
|
|
203
|
+
cursor: {
|
|
204
|
+
'': 'pointer',
|
|
205
|
+
disabled: 'not-allowed',
|
|
206
|
+
},
|
|
207
|
+
transition: 'theme',
|
|
208
|
+
},
|
|
209
|
+
});
|
|
210
|
+
```
|
|
211
|
+
|
|
212
|
+
### Phase 5 -- Standardize style props and sub-elements
|
|
213
|
+
|
|
214
|
+
Define which style props each component category exposes. Layout components get flow/gap/padding. Interactive components get positioning. Compound components declare sub-elements.
|
|
215
|
+
|
|
216
|
+
```tsx
|
|
217
|
+
const Card = tasty({
|
|
218
|
+
styles: {
|
|
219
|
+
recipe: 'card elevated',
|
|
220
|
+
Title: { preset: 'h3', color: '#primary' },
|
|
221
|
+
Content: { color: '#text', preset: 't2' },
|
|
222
|
+
},
|
|
223
|
+
elements: { Title: 'h2', Content: 'div' },
|
|
224
|
+
styleProps: ['padding', 'fill', 'radius'],
|
|
225
|
+
});
|
|
226
|
+
```
|
|
227
|
+
|
|
228
|
+
### Phase 6 -- Expand to full DS coverage
|
|
229
|
+
|
|
230
|
+
Migrate the remaining components, add the [ESLint plugin](https://github.com/tenphi/eslint-plugin-tasty) to enforce style conventions at lint time, and consider [zero-runtime mode](tasty-static.md) for static or performance-critical pages.
|
|
231
|
+
|
|
232
|
+
---
|
|
233
|
+
|
|
234
|
+
## What changes for product engineers
|
|
235
|
+
|
|
236
|
+
When a DS is powered by Tasty, product engineers typically interact with **components, not Tasty itself**. Here is what changes from their perspective:
|
|
237
|
+
|
|
238
|
+
**They do not write CSS directly.** Styling decisions are embedded in the components the DS provides. Product code consumes components, tokens, and style props.
|
|
239
|
+
|
|
240
|
+
**Overrides use styled wrappers.** Instead of passing one-off `className` or `style` props, product engineers extend components:
|
|
241
|
+
|
|
242
|
+
```tsx
|
|
243
|
+
import { tasty } from '@tenphi/tasty';
|
|
244
|
+
import { Button } from 'my-ds';
|
|
245
|
+
|
|
246
|
+
// Replace mode: providing '' (default) key replaces the parent's fill entirely
|
|
247
|
+
const DangerButton = tasty(Button, {
|
|
248
|
+
styles: {
|
|
249
|
+
fill: { '': '#danger', ':hover': '#danger-hover' },
|
|
250
|
+
},
|
|
251
|
+
});
|
|
252
|
+
|
|
253
|
+
// Extend mode: omitting '' key preserves parent states and adds/overrides
|
|
254
|
+
const LoadingButton = tasty(Button, {
|
|
255
|
+
styles: {
|
|
256
|
+
fill: {
|
|
257
|
+
loading: '#yellow', // new state appended
|
|
258
|
+
disabled: '#gray.20', // existing state overridden in place
|
|
259
|
+
},
|
|
260
|
+
},
|
|
261
|
+
});
|
|
262
|
+
```
|
|
263
|
+
|
|
264
|
+
**Style props replace raw CSS.** Layout, spacing, and positioning are controlled through typed props on the components that expose them:
|
|
265
|
+
|
|
266
|
+
```tsx
|
|
267
|
+
<Space flow="row" gap="2x" placeItems="center">
|
|
268
|
+
<Title>Dashboard</Title>
|
|
269
|
+
<Button placeSelf="end">Add Item</Button>
|
|
270
|
+
</Space>
|
|
271
|
+
```
|
|
272
|
+
|
|
273
|
+
**Components are server components by default.** All `tasty()` components and style functions are hook-free, so they work as React Server Components without `'use client'`. In server-only contexts (Next.js RSC, Astro without `client:*` directives), they produce zero client JavaScript. Product engineers only add `'use client'` when their component needs actual React interactivity (state, effects, event handlers), never because of styling.
|
|
274
|
+
|
|
275
|
+
**No cascade/specificity concerns.** Tasty's mutually exclusive selectors mean extending a component cannot accidentally break another. Import order, class name collisions, and specificity arithmetic are non-issues.
|
|
276
|
+
|
|
277
|
+
---
|
|
278
|
+
|
|
279
|
+
## Migration and Interop Notes
|
|
280
|
+
|
|
281
|
+
- **From Tailwind**: keep utility-authored product surfaces as-is at first, and use Tasty to build or replace the design-system primitives underneath them instead of forcing an all-at-once markup rewrite.
|
|
282
|
+
- **From CSS-in-JS libraries**: start with shared primitives such as `Box`, `Text`, and `Button`, preserve the external component API, and move state logic into Tasty state maps so behavior changes without product-code churn.
|
|
283
|
+
- **From CSS Modules or plain CSS**: migrate token definitions and repeated patterns first, then wrap existing DOM structure with `tasty()` components gradually rather than converting every stylesheet at once.
|
|
284
|
+
|
|
285
|
+
---
|
|
286
|
+
|
|
287
|
+
## Learn more
|
|
288
|
+
|
|
289
|
+
- [README](../README.md) -- overview, quick start, and feature highlights
|
|
290
|
+
- [Getting Started](getting-started.md) -- installation, first component, tooling setup
|
|
291
|
+
- [Methodology](methodology.md) -- the recommended patterns for structuring Tasty components
|
|
292
|
+
- [Building a Design System](design-system.md) -- practical guide to building a DS layer with Tasty
|
|
293
|
+
- [Style DSL](dsl.md) -- state maps, tokens, units, extending semantics, keyframes, @property
|
|
294
|
+
- [React API](react-api.md) -- `tasty()` factory, component props, variants, sub-elements, style functions
|
|
295
|
+
- [Configuration](configuration.md) -- tokens, recipes, custom units, style handlers, and TypeScript extensions
|
|
296
|
+
- [Style Properties](styles.md) -- complete reference for all enhanced style properties
|
|
297
|
+
- [Comparison](comparison.md) -- positioning and trade-offs vs. other styling systems
|
|
298
|
+
- [Zero Runtime (tastyStatic)](tasty-static.md) -- build-time static styling with Babel plugin
|