From 90fae32f7e5efe870528a4c23ed32319ef86dea7 Mon Sep 17 00:00:00 2001 From: Anber Date: Thu, 8 Feb 2024 10:52:08 +0000 Subject: [PATCH] =?UTF-8?q?Deploying=20to=20gh-pages=20from=20@=20Anber/wy?= =?UTF-8?q?w-in-js@0af626b9bcdc420fa26a69e537e5693c36fdc949=20=F0=9F=9A=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 404.html | 2 +- .../_buildManifest.js | 0 .../_ssgManifest.js | 0 _next/static/chunks/nextra-data-en-US.json | 2 +- bundlers/esbuild.html | 4 ++-- bundlers/rollup.html | 4 ++-- bundlers/svelte.html | 4 ++-- bundlers/vite.html | 4 ++-- bundlers/webpack.html | 4 ++-- changelog.html | 4 ++-- configuration.html | 4 ++-- feature-flags.html | 4 ++-- how-it-works.html | 4 ++-- how-to/custom-tagged-template.html | 4 ++-- index.html | 4 ++-- 15 files changed, 24 insertions(+), 24 deletions(-) rename _next/static/{drrCjZV3pnMtW7AnYMrvY => Wu9sHTlEHu0MUvoJ0_K8E}/_buildManifest.js (100%) rename _next/static/{drrCjZV3pnMtW7AnYMrvY => Wu9sHTlEHu0MUvoJ0_K8E}/_ssgManifest.js (100%) diff --git a/404.html b/404.html index 197cafea..8daaacf9 100644 --- a/404.html +++ b/404.html @@ -1 +1 @@ -404: This page could not be found

404

This page could not be found.

\ No newline at end of file +404: This page could not be found

404

This page could not be found.

\ No newline at end of file diff --git a/_next/static/drrCjZV3pnMtW7AnYMrvY/_buildManifest.js b/_next/static/Wu9sHTlEHu0MUvoJ0_K8E/_buildManifest.js similarity index 100% rename from _next/static/drrCjZV3pnMtW7AnYMrvY/_buildManifest.js rename to _next/static/Wu9sHTlEHu0MUvoJ0_K8E/_buildManifest.js diff --git a/_next/static/drrCjZV3pnMtW7AnYMrvY/_ssgManifest.js b/_next/static/Wu9sHTlEHu0MUvoJ0_K8E/_ssgManifest.js similarity index 100% rename from _next/static/drrCjZV3pnMtW7AnYMrvY/_ssgManifest.js rename to _next/static/Wu9sHTlEHu0MUvoJ0_K8E/_ssgManifest.js diff --git a/_next/static/chunks/nextra-data-en-US.json b/_next/static/chunks/nextra-data-en-US.json index 286b7b19..6af7dcf3 100644 --- a/_next/static/chunks/nextra-data-en-US.json +++ b/_next/static/chunks/nextra-data-en-US.json @@ -1 +1 @@ -{"/bundlers/esbuild":{"title":"Usage with esbuild","data":{"installation#Installation":"npm i -D @wyw-in-js/esbuild\npnpm add -D @wyw-in-js/esbuild\nyarn add --dev @wyw-in-js/esbuild\nbun add --dev @wyw-in-js/esbuild","configuration#Configuration":"import wyw from '@wyw-in-js/esbuild';\nimport esbuild from 'esbuild';\nconst prod = process.env.NODE_ENV === 'production';\nesbuild\n .build({\n filter: /\\.(js|jsx|ts|tsx)$/,\n entryPoints: ['src/index.ts'],\n outdir: 'dist',\n bundle: true,\n minify: prod,\n plugins: [\n wyw({\n sourceMap: prod,\n }),\n ],\n })\n .catch(() => process.exit(1));"}},"/bundlers/rollup":{"title":"Usage with Rollup","data":{"installation#Installation":"To use WyW-in-JS with Rollup, you need to use it together with a plugin which handles CSS files, such as rollup-plugin-css-only:\nnpm i -D rollup-plugin-css-only @wyw-in-js/rollup\npnpm add -D rollup-plugin-css-only @wyw-in-js/rollup\nyarn add --dev rollup-plugin-css-only @wyw-in-js/rollup\nbun add --dev rollup-plugin-css-only @wyw-in-js/rollup","configuration#Configuration":"import wyw from '@wyw-in-js/rollup';\nimport css from 'rollup-plugin-css-only';\nexport default {\n plugins: [\n wyw({\n sourceMap: process.env.NODE_ENV !== 'production',\n }),\n css({\n output: 'styles.css',\n }),\n ],\n};\nIf you are using @rollup/plugin-babel as well, ensure the wyw plugin is declared earlier in the plugins array than your babel plugin.\nimport wyw from '@wyw-in-js/rollup';\nimport css from 'rollup-plugin-css-only';\nimport babel from '@rollup/plugin-babel';\nexport default {\n plugins: [\n wyw({\n sourceMap: process.env.NODE_ENV !== 'production',\n }),\n css({\n output: 'styles.css',\n }),\n babel({}),\n /* rest of your plugins */\n ],\n};"}},"/bundlers/svelte":{"title":"Usage with Svelte","data":{"contents#Contents":"Svelte with Rollup\nSvelte with Webpack","rollup#Rollup":"Take a look: d964432Install rollup-plugin-css-only and update rollup.config.js\nimport svelte from 'rollup-plugin-svelte';\nimport css from 'rollup-plugin-css-only'; // for CSS bundling\nimport wyw from '@wyw-in-js/rollup';\nconst dev = process.env.NODE_ENV !== 'production';\nexport default {\n ...\n plugins: [\n svelte({\n dev,\n // allow `plugin-css-only` to bundle with CSS generated by wyw\n emitCss: true,\n }),\n wyw({\n sourceMap: dev,\n }),\n css({\n output: '/bundle.css',\n }),\n ],\n};\nIMPORTANT: rollup-plugin-css-only generates incorrect sourcemaps (see thgh/rollup-plugin-css-only#10). Use an alternative CSS plugin such as rollup-plugin-postcss instead in the same way as above.","webpack#Webpack":"Take a look: 5ffd69dUpdate webpack.config.js with the following:\nconst prod = process.env.NODE_ENV === 'production';\nconst wywLoader = {\n loader: '@wyw-in-js/webpack-loader',\n options: {\n sourceMap: !prod,\n },\n};\nmodule.exports = {\n ...\n module: {\n rules: [\n {\n test: /\\.m?js$/,\n exclude: /node_modules/,\n use: [wywLoader],\n },\n {\n test: /\\.svelte$/,\n use: [\n wywLoader,\n {\n loader: 'svelte-loader',\n options: {\n dev: !prod,\n emitCss: true,\n hotReload: true,\n },\n },\n ],\n },\n ...(CSS rules)\n ],\n },\n};"}},"/bundlers/vite":{"title":"Usage with Vite","data":{"installation#Installation":"Since Vite supports Rollup plugin Since Vite provides more features and flexibility, WyW-in-JS has a separate plugin for it @wyw-in-js/vite. Vite handles CSS by itself, you don't need a css plugin.\nnpm i -D @wyw-in-js/vite\npnpm add -D @wyw-in-js/vite\nyarn add --dev @wyw-in-js/vite\nbun add --dev @wyw-in-js/vite","configuration#Configuration":"import { defineConfig } from 'vite';\nimport wyw from '@wyw-in-js/vite';\nexport default defineConfig(() => ({\n // ...\n plugins: [wyw()],\n}));\nIf you are using language features that requires a babel transform (such as typescript), ensure the proper babel presets or plugins are passed to wyw.\nimport { defineConfig } from 'vite';\nimport wyw from '@wyw-in-js/vite';\n// example to support typescript syntax:\nexport default defineConfig(() => ({\n // ...\n plugins: [\n wyw({\n include: ['**/*.{ts,tsx}'],\n babelOptions: {\n presets: ['@babel/preset-typescript', '@babel/preset-react'],\n },\n }),\n ],\n}));"}},"/bundlers/webpack":{"title":"Usage with Webpack","data":{"installation#Installation":"npm i -D @wyw-in-js/webpack-loader\npnpm add -D @wyw-in-js/webpack-loader\nyarn add --dev @wyw-in-js/webpack-loader\nbun add --dev @wyw-in-js/webpack-loader","configuration#Configuration":"module.exports = {\n module: {\n rules: [\n {\n test: /\\.js/,\n use: [{ loader: '@wyw-in-js/webpack-loader' }],\n },\n ],\n },\n};"}},"/changelog":{"title":"Changelog","data":{}},"/how-it-works":{"title":"How it works?","data":{"":"This page is a stub. Help us expand it by contributing!"}},"/":{"title":"Index","data":{}},"/configuration":{"title":"Configuration","data":{"":"WyW-in-JS can be customized using a JavaScript, JSON or YAML file. This can be in form of:\nwyw-in-js.config.js JS file exporting the object (recommended).\nwyw-in-js property in a package.json file.\n.wyw-in-jsrc file with JSON or YAML syntax.\n.wyw-in-jsrc.json, .wyw-in-jsrc.yaml, .wyw-in-jsrc.yml, or .wyw-in-jsrc.js file.\nExample wyw-in-js.config.js:\nmodule.exports = {\n evaluate: true,\n displayName: false,\n};","options#Options":"evaluate: boolean (default: true):\nEnabling this will evaluate dynamic expressions in the CSS. You need to enable this if you want to use imported variables in the CSS or interpolate other components. Enabling this also ensures that your styled components wrapping other styled components will have the correct specificity and override styles properly.\ndisplayName: boolean (default: false):\nEnabling this will add a display name to generated class names, e.g. .Title_abcdef instead of `.abcdef'. It is disabled by default to generate smaller CSS files.\nvariableNameConfig: \"var\" | \"dashes\" | \"raw\" (default: var):\nConfigures how the variable will be formatted in final CSS.","possible-values#Possible values":"","var#var":"Use full css variable structure. This is default behavior.\nimport { styled } from \"@linaria/react\";\nexport const MyComponent = styled.div`\n color: ${(props) => props.color};\n`;\nIn CSS you will see full variable declaration\n.MyComponent_m1cus5as {\n color: var(--m1cus5as-0);\n}","dashes#dashes":"Removes var() around the variable name. It is useful when you want to control the variable on your own. For example you can set default value for CSS variable.\nimport { styled } from \"@linaria/react\";\nexport const Theme = styled.div`\n --font-color: red;\n`;\nexport const MyComponent = styled.div`\n // Returning empty string is mandatory\n // Otherwise you will have \"undefined\" in css variable value\n color: var(${(props) => props.color ?? \"\"}, var(--font-color));\n`;\nfunction App() {\n return (\n \n Text with red color\n Text with blue color\n \n );\n}\nIn CSS you will see generated variable name and your default value.\n.Theme_t1cus5as {\n --font-color: red;\n}\n.MyComponent_mc195ga {\n color: var(--mc195ga-0, var(--font-color));\n}","raw#raw":"Use only variable name without dashes and var() wrapper.\nimport { styled } from \"@linaria/react\";\nexport const MyComponent = styled.div`\n color: ${(props) => props.color};\n`;\nIn CSS you will see just the variable name. This is not valid value for css property.\n.MyComponent_mc195ga {\n color: mc195ga-0;\n}\nYou will have to make it valid:\nexport const MyComponent = styled.div`\n color: var(--${(props) => props.color});\n`;\nclassNameSlug: string | ((hash: string, title: string, args: ClassNameSlugVars) => string) (default: default):\nUsing this will provide an interface to customize the output of the CSS class name. Example:classNameSlug: '[title]',Would generate a class name such as .header instead of the default .header_absdjfsdf which includes a hash.You may also use a function to define the slug. The function will be evaluated at build time and must return a string:classNameSlug: (hash, title) => ${hash}__${7 * 6}__${title},Would generate the class name .absdjfsdf__42__header.Last argument args is an object that contains following properties: title, hash, dir, ext, file, name. These properties\nare useful when you want to generate your own hash:\nconst sha1 = require(\"sha1\");\nmodule.exports = {\n classNameSlug: (hash, title, args) => sha1(`${args.name}-${title}`)\n};\nnote invalid characters will be replaced with an underscore (_).","variables#Variables":"hash: The hash of the content.\ntitle: The name of the class.\nvariableNameSlug: string | ((context: IVariableContext) => string) (default: default):\nUsing this will provide an interface to customize the output of the CSS variable name. Example:variableNameSlug: '[componentName]-[valueSlug]-[index]',Would generate a variable name such as --Title-absdjfsdf-0 instead of the @react/styled's default --absdjfsdf-0.You may also use a function to define the slug. The function will be evaluated at build time and must return a string:variableNameSlug: (context) => ${context.valueSlug}__${context.componentName}__${context.precedingCss.match(/([\\w-]+)\\s*:\\s*$/)[1]},Would generate the variable name --absdjfsdf__Title__flex-direction.note invalid characters will be replaced with an underscore (_).","variables-1#Variables":"componentName - the displayName of the component.\ncomponentSlug - the component slug.\nindex - the index of the css variable in the current component.\nprecedingCss - the preceding part of the css for the variable, i.e. flex: 1; flex-direction: .\npreprocessor - the preprocessor used to process the tag (e.g. 'StyledProcessor' or 'AtomicStyledProcessor').\nsource - the string source of the css property value.\nunit - the unit.\nvalueSlug - the value slug.\noverrideContext: (context: Partial, filename: string) => Partial\nA custom function to override the context used to evaluate modules. This can be used to add custom globals or override the default ones.\nmodule.exports = {\n overrideContext: (context, filename) => ({\n ...context,\n HighLevelAPI: () => \"I'm a high level API\",\n }),\n};\nrules: EvalRule[]\nThe set of rules that defines how the matched files will be transformed during the evaluation.\nEvalRule is an object with two fields:\ntest is a regular expression or a function (path: string) => boolean;\naction is an Evaluator function, \"ignore\" or a name of the module that exports Evaluator function as a default export.\nIf test is omitted, the rule is applicable for all the files.The last matched rule is used for transformation. If the last matched action for a file is \"ignore\" the file will be evaluated as is, so that file must not contain any js code that cannot be executed in nodejs environment (it's usually true for any lib in node_modules).If you need to compile certain modules under /node_modules/ (which can be the case in monorepo projects), it's recommended to do it on a module by module basis for faster transforms, e.g. ignore: /node_modules[\\/\\\\](?!some-module|other-module)/. Example is using Regular Expressions negative lookahead.The Information about Evaluator, its default setting and custom implementations can be founded it evaluators section of How it works docsThe default setup is:\nimport { shaker } from '@wyw-in-js/transform';\n[\n {\n action: shaker,\n },\n {\n test: /[\\\\/]node_modules[\\\\/]/,\n action: 'ignore',\n },\n {\n test: (filename, code) => {\n if (!/[\\\\/]node_modules[\\\\/]/.test(filename)) {\n return false;\n }\n return /(?:^|\\*\\/|;|})\\s*(?:export|import)[\\s{]/m.test(code);\n },\n action: shaker,\n }\n];\ntagResolver: (source, tag) => string\nA custom function to use when resolving template tags.By default, linaria APIs like css and styled must be imported directly from the package – this is because babel needs to be able to recognize the API's to do static style extraction. tagResolver allows css and styled APIs to be imported from other files too.tagResolver takes the path for the source module (eg. @linaria/core) and the name of imported tag (eg. css), and returns the full path to the related processor. If tagResolver returns null, the default tag processor will be used.For example, we can use this to map @linaria/core , @linaria/react or @linaria/atomic where we re-export the module.\n{\n tagResolver: (source, tag) => {\n const pathToLocalFile = join(__dirname, './my-local-folder/linaria.js');\n if (source === pathToLocalFile) {\n if (tag === 'css') {\n return require.resolve('@linaria/core/processors/css');\n }\n if (tag === 'styled') {\n return require.resolve('@linaria/react/processors/styled');\n }\n }\n return null;\n };\n}\nWe can then re-export and use linaria API's from ./my-local-folder:\n// my-file.js\nimport { css, styled } from './my-local-folder/linaria';\nexport const MyComponent = styled.div`\n color: red;\n`;\nexport default css`\n border: 1px solid black;\n`;\n// ./my-local-folder/core.js\nexport * from '@linaria/core';\nbabelOptions: Object\nIf you need to specify custom babel configuration, you can pass them here. These babel options will be used by Linaria when parsing and evaluating modules.\nfeatures: Record\nA map of feature flags to enable/disable. See Feature Flags for more information.","wyw-in-jsbabel-preset#@wyw-in-js/babel-preset":"The preset pre-processes and evaluates the CSS. The bundler plugins use this preset under the hood. You also might want to use this preset if you import the components outside of the files handled by your bundler, such as on your server or in unit tests.To use this preset, add @wyw-in-js/babel-preset to your Babel configuration at the end of the presets list:.babelrc:\n{\n \"presets\": [\n \"@babel/preset-env\",\n \"@babel/preset-react\",\n+ \"@wyw-in-js\"\n ]\n}\nThe babel preset can accept the same options supported by the configuration file, however it's recommended to use the configuration file directly."}},"/feature-flags":{"title":"Feature Flags","data":{"":"Feature flags are used to enable or disable specific features provided. The features option in the configuration allows you to control the availability of these features.","syntax-for-specifying-flags#Syntax for Specifying Flags":"true: Enables the feature for all files.\nfalse: Disables the feature for all files.\n\"glob\": Enables the feature only for files that match the specified glob pattern.\n[\"glob1\", \"glob2\"]: Enables the feature for files matching any of the specified glob patterns.\n[\"glob1\", \"!glob2\"]: Enables the feature for files matching glob1 but excludes files that match glob2.\nThe dangerousCodeRemover is a flag that is enabled by default. It is designed to enhance the static evaluation of values that are interpolated in styles and to optimize the processing of styled-wrapped components during the build stage. This optimization is crucial for maintaining a stable and fast build process. It is important to note that the dangerousCodeRemover does not impact the runtime code; it solely focuses on the code used during the build.","how-it-works#How It Works":"During the build process, WyW-in-JS statically analyzes the CSS-in-JS codebase and evaluates the styles and values that are being interpolated. The dangerousCodeRemover steps in at this stage to remove potentially unsafe code, which includes code that might interact with browser-specific APIs, make HTTP requests, or perform other runtime-specific operations. By removing such code, the evaluation becomes more reliable, predictable, and efficient.","benefits#Benefits":"Enabling the dangerousCodeRemover feature provides several benefits:\nStability: The removal of potentially unsafe code ensures that the build process remains stable. It minimizes the chances of encountering build-time errors caused by unsupported browser APIs or non-static operations.\nPerformance: Removing unnecessary code results in faster build times. The build tool can efficiently process and evaluate the styles and components without unnecessary overhead, leading to quicker development cycles.","fine-tuning-the-removal#Fine-Tuning the Removal":"While the dangerousCodeRemover is highly effective at optimizing the build process, there may be cases where it becomes overly aggressive and removes code that is actually required for your specific use case. In such situations, you have the flexibility to fine-tune the behavior of the remover.By leveraging the features option in the configuration, you can selectively disable the dangerousCodeRemover for specific files. This allows you to preserve valuable code that may not be safely evaluated during the build process.","example#Example":"Suppose you have a file named specialComponent.js that contains code that should not be deleted. By adding the following entry to your features configuration:\n{\n features: {\n dangerousCodeRemover: [\"**/*\", \"!**/specialComponent.js\"],\n },\n}\nYou are instructing WyW-in-JS to exclude the specialComponent.js file from the removal process. As a result, any code within this file that would have been removed by the dangerousCodeRemover will be retained in the build output.The globalCache is enabled by default. WyW-in-JS uses two levels of caching to improve the performance of the build process. The first level is used to cache transformation and evaluation results for each transform call, usually a single call of Webpack's loader or Vite's transform hook. The second level is used to cache the results of the entire build process. The globalCache feature controls the second level of caching. Turning off this feature will result in a slower build process but decreased memory usage.The happyDOM is enabled by default. This feature enables usage of https://github.com/capricorn86/happy-dom to emulate a browser environment during the build process. Typically, the dangerousCodeRemover feature should remove all browser-related code. However, some libraries may still contain browser-specific code that cannot be statically evaluated. In such cases, the happyDOM feature can be used to emulate a browser environment during the build process. This allows WyW-in-JS to evaluate the code without encountering errors caused by missing browser APIs.The softErrors is disabled by default. It is designed to provide a more lenient evaluation of styles and values that are interpolated in styles. This flag is useful for debugging and prevents the build from failing even if some files cannot be processed with WyW-in-JS.The useBabelConfigs feature is enabled by default. If it is enabled, WyW-in-JS will try to resolve the .babelrc file for each processed file. Otherwise, it will use the default Babel configuration from babelOptions in the configuration.Please note that the default value of useBabelConfigs will be changed to false in the next major release."}},"/how-to/custom-tagged-template":{"title":"Creating Custom Tagged Template Processors","data":{"":"In the wyw-in-js toolkit, you can create custom processors for handling tagged templates. This guide will walk you through the process of creating custom tagged template processors.","overview#Overview":"A tagged template processor is a class that extends the TaggedTemplateProcessor class from the @wyw-in-js/processor-utils package. This class provides a set of methods and properties that you can override to customize the behavior of the processor.","creating-a-processor#Creating a Processor":"To create a processor, you need to define a class that extends TaggedTemplateProcessor. The constructor of your class should call the super method with the appropriate parameters.\nimport { TaggedTemplateProcessor } from '@wyw-in-js/processor-utils';\nexport default class MyProcessor extends TaggedTemplateProcessor {\n constructor(params: Params, ...args: TailProcessorParams) {\n super(params, ...args);\n }\n}\nThe Params type is an array of Param types, which represent the different ways a custom processor can be called. Each Param type corresponds to a different call pattern:\nCalleeParam: This represents a call where the processor is directly invoked with a template literal, like css```. The first element of the array is the string 'callee', and the second element is an Identifier or MemberExpression, which represents the processor being called (e.g., css`).\nCallParam: This represents a call where the processor is invoked with a function call, like `styled(SomeTag)```. The first element of the array is the string 'call', and the rest of the elements are ExpressionValues, which represent the arguments passed to the function call.\nMemberParam: This represents a call where the processor is invoked on a member, like `styled.div```. The first element of the array is the string 'member', and the second element is a string, which represents the member being accessed (e.g., 'div').\nTemplateParam: This represents a call where the processor is invoked with a template literal, like `styled```. The first element of the array is the string 'template', and the second element is an array of TemplateElements or ExpressionValues, which represent the contents of the template literal.\nIn summary, the Params type is used to capture the different ways a custom processor can be invoked, and the specific arguments or members used in the invocation.The styled.div call with a template literal color: red would be represented in the Params type as follows:\nconst params: Params = [\n ['callee', { /* Identifier or MemberExpression representing 'styled' */ }],\n ['member', 'div'],\n ['template', [\n { /* TemplateElement representing 'color: red' */ }\n ]]\n];\nIn this example:\nThe first element of the Params array is a CalleeParam representing the styled function.\nThe second element is a MemberParam representing the div member of the styled object.\nThe third element is a TemplateParam representing the template literal color: red.\nThe actual Identifier, MemberExpression, and TemplateElement instances would be generated by a parser like Babel when parsing the source code.","isvalidparams#isValidParams":"The isValidParams function is a type guard that checks if the provided params array matches the structure defined by the constraints array. It returns a boolean indicating whether the params array is valid according to the constraints.The constraints array is an array of ParamConstraint types, which can be a ParamName (i.e., 'callee', 'call', 'member', 'template'), an array of ParamName, or a wildcard '*'. The '...' in the constraints array indicates that any number of any type of params can follow.The function iterates over the params and constraints arrays simultaneously. If it encounters a '...' in the constraints, it immediately returns true, as '...' allows any number of any params. If it encounters a '*', it checks if the corresponding param is defined. If it is not, it returns false. If the constraint is an array, it checks if the param's type is in the array. If it is not, it returns false. If the constraint is a ParamName, it checks if the param's type matches the ParamName. If it does not, it returns false.If the function iterates over all the params and constraints without returning false, it returns true, indicating that the params array is valid according to the constraints.","overriding-methods#Overriding Methods":"The TaggedTemplateProcessor class provides several methods that you can override to customize the behavior of your processor.","get-asselector#get asSelector()":"This getter should return a string that represents the CSS selector for the styles defined in the tagged template.","get-value#get value()":"This getter should return an Expression that represents the value of the tagged template. This value will replace the tagged template at runtime.For simple cases like css, it is just a string literal with a class name. For styled, it is an object with some metadata, such as the class name and information about extending.Here is an example of how the value getter might be implemented in a class that extends TaggedTemplateProcessor:\npublic override get value(): ObjectExpression {\n const t = this.astService;\n return t.objectExpression([\n t.objectProperty(\n t.stringLiteral('className'),\n t.stringLiteral(this.className)\n ),\n t.objectProperty(\n t.stringLiteral('extends'),\n this.extendsNode\n ? t.callExpression(t.identifier(this.extendsNode), [])\n : t.nullLiteral()\n ),\n ]);\n}\nIn this example, the value getter returns an ObjectExpression that includes the class name and information about extending. The extendsNode is a hypothetical property that represents the node that the current node extends. If extendsNode is not defined, a nullLiteral is returned.","addinterpolationnode-expression-precedingcss-string-source-string-unit--#addInterpolation(node: Expression, precedingCss: string, source: string, unit = '')":"This method is called when an interpolation is found in the tagged template. It should return a string that represents the identifier of the interpolation.","doevaltimereplacement#doEvaltimeReplacement()":"This method is called during the evaluation phase. It should replace the tagged template with the appropriate value.","doruntimereplacement#doRuntimeReplacement()":"This method is called during the runtime phase. It should replace the tagged template with the appropriate value.","extractrulesvaluecache-valuecache-csstext-string-loc-sourcelocation--null#extractRules(valueCache: ValueCache, cssText: string, loc?: SourceLocation | null)":"This method is called to extract the CSS rules from the tagged template. It should return an object that represents the CSS rules.","tostring#toString()":"This method should return a string that represents the source code of the tagged template.","example#Example":"Here is an example of a custom processor that handles styled tagged templates:\nimport { TaggedTemplateProcessor, validateParams } from '@wyw-in-js/processor-utils';\nimport type { Params, TailProcessorParams } from '@wyw-in-js/processor-utils';\nexport default class StyledProcessor extends TaggedTemplateProcessor {\n constructor(params: Params, ...args: TailProcessorParams) {\n validateParams(params, ['callee', '*', '...'], TaggedTemplateProcessor.SKIP);\n super(params, ...args);\n }\n public override get asSelector(): string {\n return `.${this.className}`;\n }\n // ... other methods\n}\nIn this example, the StyledProcessor class extends TaggedTemplateProcessor and overrides several methods to handle styled tagged templates. The asSelector getter returns a CSS class selector based on the className property of the processor.Please refer to the css.ts and styled.ts files for more detailed examples of custom processors."}}} \ No newline at end of file +{"/bundlers/esbuild":{"title":"Usage with esbuild","data":{"installation#Installation":"npm i -D @wyw-in-js/esbuild\npnpm add -D @wyw-in-js/esbuild\nyarn add --dev @wyw-in-js/esbuild\nbun add --dev @wyw-in-js/esbuild","configuration#Configuration":"import wyw from '@wyw-in-js/esbuild';\nimport esbuild from 'esbuild';\nconst prod = process.env.NODE_ENV === 'production';\nesbuild\n .build({\n filter: /\\.(js|jsx|ts|tsx)$/,\n entryPoints: ['src/index.ts'],\n outdir: 'dist',\n bundle: true,\n minify: prod,\n plugins: [\n wyw({\n sourceMap: prod,\n }),\n ],\n })\n .catch(() => process.exit(1));"}},"/bundlers/rollup":{"title":"Usage with Rollup","data":{"installation#Installation":"To use WyW-in-JS with Rollup, you need to use it together with a plugin which handles CSS files, such as rollup-plugin-css-only:\nnpm i -D rollup-plugin-css-only @wyw-in-js/rollup\npnpm add -D rollup-plugin-css-only @wyw-in-js/rollup\nyarn add --dev rollup-plugin-css-only @wyw-in-js/rollup\nbun add --dev rollup-plugin-css-only @wyw-in-js/rollup","configuration#Configuration":"import wyw from '@wyw-in-js/rollup';\nimport css from 'rollup-plugin-css-only';\nexport default {\n plugins: [\n wyw({\n sourceMap: process.env.NODE_ENV !== 'production',\n }),\n css({\n output: 'styles.css',\n }),\n ],\n};\nIf you are using @rollup/plugin-babel as well, ensure the wyw plugin is declared earlier in the plugins array than your babel plugin.\nimport wyw from '@wyw-in-js/rollup';\nimport css from 'rollup-plugin-css-only';\nimport babel from '@rollup/plugin-babel';\nexport default {\n plugins: [\n wyw({\n sourceMap: process.env.NODE_ENV !== 'production',\n }),\n css({\n output: 'styles.css',\n }),\n babel({}),\n /* rest of your plugins */\n ],\n};"}},"/bundlers/svelte":{"title":"Usage with Svelte","data":{"contents#Contents":"Svelte with Rollup\nSvelte with Webpack","rollup#Rollup":"Take a look: d964432Install rollup-plugin-css-only and update rollup.config.js\nimport svelte from 'rollup-plugin-svelte';\nimport css from 'rollup-plugin-css-only'; // for CSS bundling\nimport wyw from '@wyw-in-js/rollup';\nconst dev = process.env.NODE_ENV !== 'production';\nexport default {\n ...\n plugins: [\n svelte({\n dev,\n // allow `plugin-css-only` to bundle with CSS generated by wyw\n emitCss: true,\n }),\n wyw({\n sourceMap: dev,\n }),\n css({\n output: '/bundle.css',\n }),\n ],\n};\nIMPORTANT: rollup-plugin-css-only generates incorrect sourcemaps (see thgh/rollup-plugin-css-only#10). Use an alternative CSS plugin such as rollup-plugin-postcss instead in the same way as above.","webpack#Webpack":"Take a look: 5ffd69dUpdate webpack.config.js with the following:\nconst prod = process.env.NODE_ENV === 'production';\nconst wywLoader = {\n loader: '@wyw-in-js/webpack-loader',\n options: {\n sourceMap: !prod,\n },\n};\nmodule.exports = {\n ...\n module: {\n rules: [\n {\n test: /\\.m?js$/,\n exclude: /node_modules/,\n use: [wywLoader],\n },\n {\n test: /\\.svelte$/,\n use: [\n wywLoader,\n {\n loader: 'svelte-loader',\n options: {\n dev: !prod,\n emitCss: true,\n hotReload: true,\n },\n },\n ],\n },\n ...(CSS rules)\n ],\n },\n};"}},"/bundlers/vite":{"title":"Usage with Vite","data":{"installation#Installation":"Since Vite supports Rollup plugin Since Vite provides more features and flexibility, WyW-in-JS has a separate plugin for it @wyw-in-js/vite. Vite handles CSS by itself, you don't need a css plugin.\nnpm i -D @wyw-in-js/vite\npnpm add -D @wyw-in-js/vite\nyarn add --dev @wyw-in-js/vite\nbun add --dev @wyw-in-js/vite","configuration#Configuration":"import { defineConfig } from 'vite';\nimport wyw from '@wyw-in-js/vite';\nexport default defineConfig(() => ({\n // ...\n plugins: [wyw()],\n}));\nIf you are using language features that requires a babel transform (such as typescript), ensure the proper babel presets or plugins are passed to wyw.\nimport { defineConfig } from 'vite';\nimport wyw from '@wyw-in-js/vite';\n// example to support typescript syntax:\nexport default defineConfig(() => ({\n // ...\n plugins: [\n wyw({\n include: ['**/*.{ts,tsx}'],\n babelOptions: {\n presets: ['@babel/preset-typescript', '@babel/preset-react'],\n },\n }),\n ],\n}));"}},"/bundlers/webpack":{"title":"Usage with Webpack","data":{"installation#Installation":"npm i -D @wyw-in-js/webpack-loader\npnpm add -D @wyw-in-js/webpack-loader\nyarn add --dev @wyw-in-js/webpack-loader\nbun add --dev @wyw-in-js/webpack-loader","configuration#Configuration":"module.exports = {\n module: {\n rules: [\n {\n test: /\\.js/,\n use: [{ loader: '@wyw-in-js/webpack-loader' }],\n },\n ],\n },\n};"}},"/changelog":{"title":"Changelog","data":{}},"/how-it-works":{"title":"How it works?","data":{"":"This page is a stub. Help us expand it by contributing!"}},"/":{"title":"Index","data":{}},"/feature-flags":{"title":"Feature Flags","data":{"":"Feature flags are used to enable or disable specific features provided. The features option in the configuration allows you to control the availability of these features.","syntax-for-specifying-flags#Syntax for Specifying Flags":"true: Enables the feature for all files.\nfalse: Disables the feature for all files.\n\"glob\": Enables the feature only for files that match the specified glob pattern.\n[\"glob1\", \"glob2\"]: Enables the feature for files matching any of the specified glob patterns.\n[\"glob1\", \"!glob2\"]: Enables the feature for files matching glob1 but excludes files that match glob2.\nThe dangerousCodeRemover is a flag that is enabled by default. It is designed to enhance the static evaluation of values that are interpolated in styles and to optimize the processing of styled-wrapped components during the build stage. This optimization is crucial for maintaining a stable and fast build process. It is important to note that the dangerousCodeRemover does not impact the runtime code; it solely focuses on the code used during the build.","how-it-works#How It Works":"During the build process, WyW-in-JS statically analyzes the CSS-in-JS codebase and evaluates the styles and values that are being interpolated. The dangerousCodeRemover steps in at this stage to remove potentially unsafe code, which includes code that might interact with browser-specific APIs, make HTTP requests, or perform other runtime-specific operations. By removing such code, the evaluation becomes more reliable, predictable, and efficient.","benefits#Benefits":"Enabling the dangerousCodeRemover feature provides several benefits:\nStability: The removal of potentially unsafe code ensures that the build process remains stable. It minimizes the chances of encountering build-time errors caused by unsupported browser APIs or non-static operations.\nPerformance: Removing unnecessary code results in faster build times. The build tool can efficiently process and evaluate the styles and components without unnecessary overhead, leading to quicker development cycles.","fine-tuning-the-removal#Fine-Tuning the Removal":"While the dangerousCodeRemover is highly effective at optimizing the build process, there may be cases where it becomes overly aggressive and removes code that is actually required for your specific use case. In such situations, you have the flexibility to fine-tune the behavior of the remover.By leveraging the features option in the configuration, you can selectively disable the dangerousCodeRemover for specific files. This allows you to preserve valuable code that may not be safely evaluated during the build process.","example#Example":"Suppose you have a file named specialComponent.js that contains code that should not be deleted. By adding the following entry to your features configuration:\n{\n features: {\n dangerousCodeRemover: [\"**/*\", \"!**/specialComponent.js\"],\n },\n}\nYou are instructing WyW-in-JS to exclude the specialComponent.js file from the removal process. As a result, any code within this file that would have been removed by the dangerousCodeRemover will be retained in the build output.The globalCache is enabled by default. WyW-in-JS uses two levels of caching to improve the performance of the build process. The first level is used to cache transformation and evaluation results for each transform call, usually a single call of Webpack's loader or Vite's transform hook. The second level is used to cache the results of the entire build process. The globalCache feature controls the second level of caching. Turning off this feature will result in a slower build process but decreased memory usage.The happyDOM is enabled by default. This feature enables usage of https://github.com/capricorn86/happy-dom to emulate a browser environment during the build process. Typically, the dangerousCodeRemover feature should remove all browser-related code. However, some libraries may still contain browser-specific code that cannot be statically evaluated. In such cases, the happyDOM feature can be used to emulate a browser environment during the build process. This allows WyW-in-JS to evaluate the code without encountering errors caused by missing browser APIs.The softErrors is disabled by default. It is designed to provide a more lenient evaluation of styles and values that are interpolated in styles. This flag is useful for debugging and prevents the build from failing even if some files cannot be processed with WyW-in-JS.The useBabelConfigs feature is enabled by default. If it is enabled, WyW-in-JS will try to resolve the .babelrc file for each processed file. Otherwise, it will use the default Babel configuration from babelOptions in the configuration.Please note that the default value of useBabelConfigs will be changed to false in the next major release."}},"/configuration":{"title":"Configuration","data":{"":"WyW-in-JS can be customized using a JavaScript, JSON or YAML file. This can be in form of:\nwyw-in-js.config.js JS file exporting the object (recommended).\nwyw-in-js property in a package.json file.\n.wyw-in-jsrc file with JSON or YAML syntax.\n.wyw-in-jsrc.json, .wyw-in-jsrc.yaml, .wyw-in-jsrc.yml, or .wyw-in-jsrc.js file.\nExample wyw-in-js.config.js:\nmodule.exports = {\n evaluate: true,\n displayName: false,\n};","options#Options":"evaluate: boolean (default: true):\nEnabling this will evaluate dynamic expressions in the CSS. You need to enable this if you want to use imported variables in the CSS or interpolate other components. Enabling this also ensures that your styled components wrapping other styled components will have the correct specificity and override styles properly.\ndisplayName: boolean (default: false):\nEnabling this will add a display name to generated class names, e.g. .Title_abcdef instead of `.abcdef'. It is disabled by default to generate smaller CSS files.\nvariableNameConfig: \"var\" | \"dashes\" | \"raw\" (default: var):\nConfigures how the variable will be formatted in final CSS.","possible-values#Possible values":"","var#var":"Use full css variable structure. This is default behavior.\nimport { styled } from \"@linaria/react\";\nexport const MyComponent = styled.div`\n color: ${(props) => props.color};\n`;\nIn CSS you will see full variable declaration\n.MyComponent_m1cus5as {\n color: var(--m1cus5as-0);\n}","dashes#dashes":"Removes var() around the variable name. It is useful when you want to control the variable on your own. For example you can set default value for CSS variable.\nimport { styled } from \"@linaria/react\";\nexport const Theme = styled.div`\n --font-color: red;\n`;\nexport const MyComponent = styled.div`\n // Returning empty string is mandatory\n // Otherwise you will have \"undefined\" in css variable value\n color: var(${(props) => props.color ?? \"\"}, var(--font-color));\n`;\nfunction App() {\n return (\n \n Text with red color\n Text with blue color\n \n );\n}\nIn CSS you will see generated variable name and your default value.\n.Theme_t1cus5as {\n --font-color: red;\n}\n.MyComponent_mc195ga {\n color: var(--mc195ga-0, var(--font-color));\n}","raw#raw":"Use only variable name without dashes and var() wrapper.\nimport { styled } from \"@linaria/react\";\nexport const MyComponent = styled.div`\n color: ${(props) => props.color};\n`;\nIn CSS you will see just the variable name. This is not valid value for css property.\n.MyComponent_mc195ga {\n color: mc195ga-0;\n}\nYou will have to make it valid:\nexport const MyComponent = styled.div`\n color: var(--${(props) => props.color});\n`;\nclassNameSlug: string | ((hash: string, title: string, args: ClassNameSlugVars) => string) (default: default):\nUsing this will provide an interface to customize the output of the CSS class name. Example:classNameSlug: '[title]',Would generate a class name such as .header instead of the default .header_absdjfsdf which includes a hash.You may also use a function to define the slug. The function will be evaluated at build time and must return a string:classNameSlug: (hash, title) => ${hash}__${7 * 6}__${title},Would generate the class name .absdjfsdf__42__header.Last argument args is an object that contains following properties: title, hash, dir, ext, file, name. These properties\nare useful when you want to generate your own hash:\nconst sha1 = require(\"sha1\");\nmodule.exports = {\n classNameSlug: (hash, title, args) => sha1(`${args.name}-${title}`)\n};\nnote invalid characters will be replaced with an underscore (_).","variables#Variables":"hash: The hash of the content.\ntitle: The name of the class.\nvariableNameSlug: string | ((context: IVariableContext) => string) (default: default):\nUsing this will provide an interface to customize the output of the CSS variable name. Example:variableNameSlug: '[componentName]-[valueSlug]-[index]',Would generate a variable name such as --Title-absdjfsdf-0 instead of the @react/styled's default --absdjfsdf-0.You may also use a function to define the slug. The function will be evaluated at build time and must return a string:variableNameSlug: (context) => ${context.valueSlug}__${context.componentName}__${context.precedingCss.match(/([\\w-]+)\\s*:\\s*$/)[1]},Would generate the variable name --absdjfsdf__Title__flex-direction.note invalid characters will be replaced with an underscore (_).","variables-1#Variables":"componentName - the displayName of the component.\ncomponentSlug - the component slug.\nindex - the index of the css variable in the current component.\nprecedingCss - the preceding part of the css for the variable, i.e. flex: 1; flex-direction: .\npreprocessor - the preprocessor used to process the tag (e.g. 'StyledProcessor' or 'AtomicStyledProcessor').\nsource - the string source of the css property value.\nunit - the unit.\nvalueSlug - the value slug.\noverrideContext: (context: Partial, filename: string) => Partial\nA custom function to override the context used to evaluate modules. This can be used to add custom globals or override the default ones.\nmodule.exports = {\n overrideContext: (context, filename) => ({\n ...context,\n HighLevelAPI: () => \"I'm a high level API\",\n }),\n};\nrules: EvalRule[]\nThe set of rules that defines how the matched files will be transformed during the evaluation.\nEvalRule is an object with two fields:\ntest is a regular expression or a function (path: string) => boolean;\naction is an Evaluator function, \"ignore\" or a name of the module that exports Evaluator function as a default export.\nIf test is omitted, the rule is applicable for all the files.The last matched rule is used for transformation. If the last matched action for a file is \"ignore\" the file will be evaluated as is, so that file must not contain any js code that cannot be executed in nodejs environment (it's usually true for any lib in node_modules).If you need to compile certain modules under /node_modules/ (which can be the case in monorepo projects), it's recommended to do it on a module by module basis for faster transforms, e.g. ignore: /node_modules[\\/\\\\](?!some-module|other-module)/. Example is using Regular Expressions negative lookahead.The Information about Evaluator, its default setting and custom implementations can be founded it evaluators section of How it works docsThe default setup is:\nimport { shaker } from '@wyw-in-js/transform';\n[\n {\n action: shaker,\n },\n {\n test: /[\\\\/]node_modules[\\\\/]/,\n action: 'ignore',\n },\n {\n test: (filename, code) => {\n if (!/[\\\\/]node_modules[\\\\/]/.test(filename)) {\n return false;\n }\n return /(?:^|\\*\\/|;|})\\s*(?:export|import)[\\s{]/m.test(code);\n },\n action: shaker,\n }\n];\ntagResolver: (source, tag) => string\nA custom function to use when resolving template tags.By default, linaria APIs like css and styled must be imported directly from the package – this is because babel needs to be able to recognize the API's to do static style extraction. tagResolver allows css and styled APIs to be imported from other files too.tagResolver takes the path for the source module (eg. @linaria/core) and the name of imported tag (eg. css), and returns the full path to the related processor. If tagResolver returns null, the default tag processor will be used.For example, we can use this to map @linaria/core , @linaria/react or @linaria/atomic where we re-export the module.\n{\n tagResolver: (source, tag) => {\n const pathToLocalFile = join(__dirname, './my-local-folder/linaria.js');\n if (source === pathToLocalFile) {\n if (tag === 'css') {\n return require.resolve('@linaria/core/processors/css');\n }\n if (tag === 'styled') {\n return require.resolve('@linaria/react/processors/styled');\n }\n }\n return null;\n };\n}\nWe can then re-export and use linaria API's from ./my-local-folder:\n// my-file.js\nimport { css, styled } from './my-local-folder/linaria';\nexport const MyComponent = styled.div`\n color: red;\n`;\nexport default css`\n border: 1px solid black;\n`;\n// ./my-local-folder/core.js\nexport * from '@linaria/core';\nbabelOptions: Object\nIf you need to specify custom babel configuration, you can pass them here. These babel options will be used by Linaria when parsing and evaluating modules.\nfeatures: Record\nA map of feature flags to enable/disable. See Feature Flags for more information.","wyw-in-jsbabel-preset#@wyw-in-js/babel-preset":"The preset pre-processes and evaluates the CSS. The bundler plugins use this preset under the hood. You also might want to use this preset if you import the components outside of the files handled by your bundler, such as on your server or in unit tests.To use this preset, add @wyw-in-js/babel-preset to your Babel configuration at the end of the presets list:.babelrc:\n{\n \"presets\": [\n \"@babel/preset-env\",\n \"@babel/preset-react\",\n+ \"@wyw-in-js\"\n ]\n}\nThe babel preset can accept the same options supported by the configuration file, however it's recommended to use the configuration file directly."}},"/how-to/custom-tagged-template":{"title":"Creating Custom Tagged Template Processors","data":{"":"In the wyw-in-js toolkit, you can create custom processors for handling tagged templates. This guide will walk you through the process of creating custom tagged template processors.","overview#Overview":"A tagged template processor is a class that extends the TaggedTemplateProcessor class from the @wyw-in-js/processor-utils package. This class provides a set of methods and properties that you can override to customize the behavior of the processor.","creating-a-processor#Creating a Processor":"To create a processor, you need to define a class that extends TaggedTemplateProcessor. The constructor of your class should call the super method with the appropriate parameters.\nimport { TaggedTemplateProcessor } from '@wyw-in-js/processor-utils';\nexport default class MyProcessor extends TaggedTemplateProcessor {\n constructor(params: Params, ...args: TailProcessorParams) {\n super(params, ...args);\n }\n}\nThe Params type is an array of Param types, which represent the different ways a custom processor can be called. Each Param type corresponds to a different call pattern:\nCalleeParam: This represents a call where the processor is directly invoked with a template literal, like css```. The first element of the array is the string 'callee', and the second element is an Identifier or MemberExpression, which represents the processor being called (e.g., css`).\nCallParam: This represents a call where the processor is invoked with a function call, like `styled(SomeTag)```. The first element of the array is the string 'call', and the rest of the elements are ExpressionValues, which represent the arguments passed to the function call.\nMemberParam: This represents a call where the processor is invoked on a member, like `styled.div```. The first element of the array is the string 'member', and the second element is a string, which represents the member being accessed (e.g., 'div').\nTemplateParam: This represents a call where the processor is invoked with a template literal, like `styled```. The first element of the array is the string 'template', and the second element is an array of TemplateElements or ExpressionValues, which represent the contents of the template literal.\nIn summary, the Params type is used to capture the different ways a custom processor can be invoked, and the specific arguments or members used in the invocation.The styled.div call with a template literal color: red would be represented in the Params type as follows:\nconst params: Params = [\n ['callee', { /* Identifier or MemberExpression representing 'styled' */ }],\n ['member', 'div'],\n ['template', [\n { /* TemplateElement representing 'color: red' */ }\n ]]\n];\nIn this example:\nThe first element of the Params array is a CalleeParam representing the styled function.\nThe second element is a MemberParam representing the div member of the styled object.\nThe third element is a TemplateParam representing the template literal color: red.\nThe actual Identifier, MemberExpression, and TemplateElement instances would be generated by a parser like Babel when parsing the source code.","isvalidparams#isValidParams":"The isValidParams function is a type guard that checks if the provided params array matches the structure defined by the constraints array. It returns a boolean indicating whether the params array is valid according to the constraints.The constraints array is an array of ParamConstraint types, which can be a ParamName (i.e., 'callee', 'call', 'member', 'template'), an array of ParamName, or a wildcard '*'. The '...' in the constraints array indicates that any number of any type of params can follow.The function iterates over the params and constraints arrays simultaneously. If it encounters a '...' in the constraints, it immediately returns true, as '...' allows any number of any params. If it encounters a '*', it checks if the corresponding param is defined. If it is not, it returns false. If the constraint is an array, it checks if the param's type is in the array. If it is not, it returns false. If the constraint is a ParamName, it checks if the param's type matches the ParamName. If it does not, it returns false.If the function iterates over all the params and constraints without returning false, it returns true, indicating that the params array is valid according to the constraints.","overriding-methods#Overriding Methods":"The TaggedTemplateProcessor class provides several methods that you can override to customize the behavior of your processor.","get-asselector#get asSelector()":"This getter should return a string that represents the CSS selector for the styles defined in the tagged template.","get-value#get value()":"This getter should return an Expression that represents the value of the tagged template. This value will replace the tagged template at runtime.For simple cases like css, it is just a string literal with a class name. For styled, it is an object with some metadata, such as the class name and information about extending.Here is an example of how the value getter might be implemented in a class that extends TaggedTemplateProcessor:\npublic override get value(): ObjectExpression {\n const t = this.astService;\n return t.objectExpression([\n t.objectProperty(\n t.stringLiteral('className'),\n t.stringLiteral(this.className)\n ),\n t.objectProperty(\n t.stringLiteral('extends'),\n this.extendsNode\n ? t.callExpression(t.identifier(this.extendsNode), [])\n : t.nullLiteral()\n ),\n ]);\n}\nIn this example, the value getter returns an ObjectExpression that includes the class name and information about extending. The extendsNode is a hypothetical property that represents the node that the current node extends. If extendsNode is not defined, a nullLiteral is returned.","addinterpolationnode-expression-precedingcss-string-source-string-unit--#addInterpolation(node: Expression, precedingCss: string, source: string, unit = '')":"This method is called when an interpolation is found in the tagged template. It should return a string that represents the identifier of the interpolation.","doevaltimereplacement#doEvaltimeReplacement()":"This method is called during the evaluation phase. It should replace the tagged template with the appropriate value.","doruntimereplacement#doRuntimeReplacement()":"This method is called during the runtime phase. It should replace the tagged template with the appropriate value.","extractrulesvaluecache-valuecache-csstext-string-loc-sourcelocation--null#extractRules(valueCache: ValueCache, cssText: string, loc?: SourceLocation | null)":"This method is called to extract the CSS rules from the tagged template. It should return an object that represents the CSS rules.","tostring#toString()":"This method should return a string that represents the source code of the tagged template.","example#Example":"Here is an example of a custom processor that handles styled tagged templates:\nimport { TaggedTemplateProcessor, validateParams } from '@wyw-in-js/processor-utils';\nimport type { Params, TailProcessorParams } from '@wyw-in-js/processor-utils';\nexport default class StyledProcessor extends TaggedTemplateProcessor {\n constructor(params: Params, ...args: TailProcessorParams) {\n validateParams(params, ['callee', '*', '...'], TaggedTemplateProcessor.SKIP);\n super(params, ...args);\n }\n public override get asSelector(): string {\n return `.${this.className}`;\n }\n // ... other methods\n}\nIn this example, the StyledProcessor class extends TaggedTemplateProcessor and overrides several methods to handle styled tagged templates. The asSelector getter returns a CSS class selector based on the className property of the processor.Please refer to the css.ts and styled.ts files for more detailed examples of custom processors."}}} \ No newline at end of file diff --git a/bundlers/esbuild.html b/bundlers/esbuild.html index 79dabd5c..c074e830 100644 --- a/bundlers/esbuild.html +++ b/bundlers/esbuild.html @@ -11,7 +11,7 @@ --nextra-primary-hue: 210deg; --nextra-primary-saturation: 100%; } -
Supported bundlers
Esbuild

Usage with esbuild

+
Supported bundlers
Esbuild

Usage with esbuild

Installation

npm i -D @wyw-in-js/esbuild

Configuration

@@ -33,4 +33,4 @@

}), ], }) - .catch(() => process.exit(1));

Custom Tagged TemplateRollup
\ No newline at end of file + .catch(() => process.exit(1));
Custom Tagged TemplateRollup
\ No newline at end of file diff --git a/bundlers/rollup.html b/bundlers/rollup.html index 4f9248c1..59d4c602 100644 --- a/bundlers/rollup.html +++ b/bundlers/rollup.html @@ -11,7 +11,7 @@ --nextra-primary-hue: 210deg; --nextra-primary-saturation: 100%; } -
Supported bundlers
Rollup

Usage with Rollup

+
Supported bundlers
Rollup

Usage with Rollup

Installation

To use WyW-in-JS with Rollup, you need to use it together with a plugin which handles CSS files, such as rollup-plugin-css-only:

npm i -D rollup-plugin-css-only @wyw-in-js/rollup
@@ -45,4 +45,4 @@

babel({}), /* rest of your plugins */ ], -};

EsbuildSvelte
\ No newline at end of file +};
EsbuildSvelte
\ No newline at end of file diff --git a/bundlers/svelte.html b/bundlers/svelte.html index e24f1758..2acb347c 100644 --- a/bundlers/svelte.html +++ b/bundlers/svelte.html @@ -11,7 +11,7 @@ --nextra-primary-hue: 210deg; --nextra-primary-saturation: 100%; } -
Supported bundlers
Svelte

Usage with Svelte

+
Supported bundlers
Svelte

Usage with Svelte

Contents

RollupVite
\ No newline at end of file +};
RollupVite
\ No newline at end of file diff --git a/bundlers/vite.html b/bundlers/vite.html index 954072bf..8a1980f8 100644 --- a/bundlers/vite.html +++ b/bundlers/vite.html @@ -11,7 +11,7 @@ --nextra-primary-hue: 210deg; --nextra-primary-saturation: 100%; } -
Supported bundlers
Vite

Usage with Vite

+
Supported bundlers
Vite

Usage with Vite

Installation

Since Vite supports Rollup plugin Since Vite provides more features and flexibility, WyW-in-JS has a separate plugin for it @wyw-in-js/vite. Vite handles CSS by itself, you don't need a css plugin.

npm i -D @wyw-in-js/vite
@@ -38,4 +38,4 @@

}, }), ], -}));

SvelteWebpack
\ No newline at end of file +}));
SvelteWebpack
\ No newline at end of file diff --git a/bundlers/webpack.html b/bundlers/webpack.html index f821a5ea..f22f527c 100644 --- a/bundlers/webpack.html +++ b/bundlers/webpack.html @@ -11,7 +11,7 @@ --nextra-primary-hue: 210deg; --nextra-primary-saturation: 100%; } -
Supported bundlers
Webpack

Usage with Webpack

+
Supported bundlers
Webpack

Usage with Webpack

Installation

npm i -D @wyw-in-js/webpack-loader

Configuration

@@ -24,4 +24,4 @@

}, ], }, -};

ViteChangelog
\ No newline at end of file +};
ViteChangelog
\ No newline at end of file diff --git a/changelog.html b/changelog.html index c6b63974..f8bcd52e 100644 --- a/changelog.html +++ b/changelog.html @@ -11,7 +11,7 @@ --nextra-primary-hue: 210deg; --nextra-primary-saturation: 100%; } -
Changelog

wyw-in-js

+
Changelog

wyw-in-js

0.3.0

Minor Changes

    @@ -57,4 +57,4 @@

  • 02973e1: @linaria/webpack5-loader has been moved and renamed into @wyw-in-js/webpack-loader. Support for Webpack 4 has been dropped.
  • e02d5d2: @linaria/babel-preset and @linaria/shaker have been merged into @wyw-in-js/transform.
    • -

WebpackConfiguration
\ No newline at end of file +
WebpackConfiguration
\ No newline at end of file diff --git a/configuration.html b/configuration.html index 28cfff45..c756c1a6 100644 --- a/configuration.html +++ b/configuration.html @@ -11,7 +11,7 @@ --nextra-primary-hue: 210deg; --nextra-primary-saturation: 100%; } -
Configuration

Configuration

+
Configuration

Configuration

WyW-in-JS can be customized using a JavaScript, JSON or YAML file. This can be in form of:

  • wyw-in-js.config.js JS file exporting the object (recommended).
    • @@ -257,4 +257,4 @@

    + "@wyw-in-js" ] }

-

The babel preset can accept the same options supported by the configuration file, however it's recommended to use the configuration file directly.

ChangelogFeature Flags
\ No newline at end of file +

The babel preset can accept the same options supported by the configuration file, however it's recommended to use the configuration file directly.

ChangelogFeature Flags
\ No newline at end of file diff --git a/feature-flags.html b/feature-flags.html index 02c88f67..ca435001 100644 --- a/feature-flags.html +++ b/feature-flags.html @@ -11,7 +11,7 @@ --nextra-primary-hue: 210deg; --nextra-primary-saturation: 100%; } -
Feature Flags

Feature Flags

+
Feature Flags

Feature Flags

Feature flags are used to enable or disable specific features provided. The features option in the configuration allows you to control the availability of these features.

Syntax for Specifying Flags

    @@ -54,4 +54,4 @@

    The softErrors is disabled by default. It is designed to provide a more lenient evaluation of styles and values that are interpolated in styles. This flag is useful for debugging and prevents the build from failing even if some files cannot be processed with WyW-in-JS.

    'useBabelConfigs' Feature

    The useBabelConfigs feature is enabled by default. If it is enabled, WyW-in-JS will try to resolve the .babelrc file for each processed file. Otherwise, it will use the default Babel configuration from babelOptions in the configuration.

    -

    Please note that the default value of useBabelConfigs will be changed to false in the next major release.

    Configuration
\ No newline at end of file +

Please note that the default value of useBabelConfigs will be changed to false in the next major release.

Configuration
\ No newline at end of file diff --git a/how-it-works.html b/how-it-works.html index dd85ab5d..6b6758fc 100644 --- a/how-it-works.html +++ b/how-it-works.html @@ -11,6 +11,6 @@ --nextra-primary-hue: 210deg; --nextra-primary-saturation: 100%; } -
How it works?

How it works?

+
\ No newline at end of file +
🚨

This page is a stub. Help us expand it by contributing!

IntroductionCustom Tagged Template
\ No newline at end of file diff --git a/how-to/custom-tagged-template.html b/how-to/custom-tagged-template.html index 4f875146..b9ca49fa 100644 --- a/how-to/custom-tagged-template.html +++ b/how-to/custom-tagged-template.html @@ -11,7 +11,7 @@ --nextra-primary-hue: 210deg; --nextra-primary-saturation: 100%; } -
How to use
Custom Tagged Template

Creating Custom Tagged Template Processors

+
How to use
Custom Tagged Template

Creating Custom Tagged Template Processors

In the wyw-in-js toolkit, you can create custom processors for handling tagged templates. This guide will walk you through the process of creating custom tagged template processors.

Overview

A tagged template processor is a class that extends the TaggedTemplateProcessor class from the @wyw-in-js/processor-utils package. This class provides a set of methods and properties that you can override to customize the behavior of the processor.

@@ -112,4 +112,4 @@

// ... other methods }

In this example, the StyledProcessor class extends TaggedTemplateProcessor and overrides several methods to handle styled tagged templates. The asSelector getter returns a CSS class selector based on the className property of the processor.

-

Please refer to the css.ts and styled.ts files for more detailed examples of custom processors.

How it works?Esbuild
\ No newline at end of file +

Please refer to the css.ts and styled.ts files for more detailed examples of custom processors.

How it works?Esbuild
\ No newline at end of file diff --git a/index.html b/index.html index 8f0882f5..3c51018a 100644 --- a/index.html +++ b/index.html @@ -11,7 +11,7 @@ --nextra-primary-hue: 210deg; --nextra-primary-saturation: 100%; } -
Introduction
+
Introduction

WyW-in-JS

A Toolkit for Zero-Runtime CSS-in-JS Libraries

@@ -26,4 +26,4 @@

Computes any unprepared JavaScript during the build phase, generating a set of artifacts that processors can transform into styles (or other outputs, depending on the processor).
  • Allows for arbitrary JavaScript in style definitions, including imports, conditionals, and loops.
  • Offers loaders and plugins for popular bundlers (including Webpack, Vite, esbuild) and frameworks (Next.js), ensuring compatibility with various build systems.
    • -
    How it works?

    \ No newline at end of file +
    How it works?
    \ No newline at end of file