tailwindcss/src/lib/sharedState.js

68 lines
1.7 KiB
JavaScript
Raw Normal View History

Separate `stable` and `oxide` engines (#10359) * separate `stable` and `oxide` mode (package.json in this case) * drop `install` script (we use a workspace now) * change required engine to 16 * enable OXIDE by default * ignore generated `oxide` files * splitup package.json scripts into "public" and "private" scripts Not ideal of course, but this should make it a tiny bit easier to know which scripts _you_ as a developer / contributor have to run. * drop `workspaces` from the `stable` engine * drop `oxide` related build files from the `stable` engine * drop `oxide` engine specific dependencies from the `stable` engine * use the `oxide-node-api-shim` for the `stable` engine * add little script to swap the engines * drop `oxide:build` from `turbo` config * configure `ci` for `stable` and `oxide` engines - rename `nodejs.yml` -> `ci.yml` - add `ci-stable.yml` (for stable mode and Node 12) - ensure to use the `stable` engine in the `ci-stable.yml` workflow - drop `oxide:___` specific scripts * rename `release-insiders` to `release-insiders-stable` This way we will be able to remove all files that contain `stable` once we are ready. * rename `release-insiders-oxide` to just `release-insiders` * cleanup insider related workflows * rename `release` -> `release-stable` * rename `release-oxide` -> `release` * change names of release workflows * drop `oxide-` prefix from jobs * inline node versions * do not use `turbo` for the stable build Can't use it because we don't have a workspace in the stable build. * re-rename CI workflow * encode default engine in relevant `package.json` files * make Node 12 work * increase `node-version` matrix * make release workflows explicit (per engine) * add `Oxide` to workflow name * add integration tests for the `oxide` engine * add integration tests for the `stable` engine * run `oxide` integrations against node `18` * run `stable` integration tests against node 18 We should test node 12 for tailwindcss, but integrations itself can run against a newer version. In fact, we always ran them against node 16. * use `localhost` instead of `0.0.0.0` * ensure `webpack-4` works on Node 18 * run relese scripst directly Instead of going via `npm`. It's a bit nicer and quicker! * drop unused scripts * sync package-lock.json * ensure to generate the plugin list before running `jest` We _could_ use an `npm run pretest`, but then you can't run `jest` directly anymore (which is required for some tools like vscode extensions). * cleanup npm scripts * drop pretend comments * fix typo * add `build:rust` as a pre-jest run script
2023-01-19 17:58:25 +01:00
import pkg from '../../package.json'
let OXIDE_DEFAULT_ENABLED = pkg.tailwindcss.engine === 'oxide'
export const env = {
NODE_ENV: process.env.NODE_ENV,
DEBUG: resolveDebug(process.env.DEBUG),
Separate `stable` and `oxide` engines (#10359) * separate `stable` and `oxide` mode (package.json in this case) * drop `install` script (we use a workspace now) * change required engine to 16 * enable OXIDE by default * ignore generated `oxide` files * splitup package.json scripts into "public" and "private" scripts Not ideal of course, but this should make it a tiny bit easier to know which scripts _you_ as a developer / contributor have to run. * drop `workspaces` from the `stable` engine * drop `oxide` related build files from the `stable` engine * drop `oxide` engine specific dependencies from the `stable` engine * use the `oxide-node-api-shim` for the `stable` engine * add little script to swap the engines * drop `oxide:build` from `turbo` config * configure `ci` for `stable` and `oxide` engines - rename `nodejs.yml` -> `ci.yml` - add `ci-stable.yml` (for stable mode and Node 12) - ensure to use the `stable` engine in the `ci-stable.yml` workflow - drop `oxide:___` specific scripts * rename `release-insiders` to `release-insiders-stable` This way we will be able to remove all files that contain `stable` once we are ready. * rename `release-insiders-oxide` to just `release-insiders` * cleanup insider related workflows * rename `release` -> `release-stable` * rename `release-oxide` -> `release` * change names of release workflows * drop `oxide-` prefix from jobs * inline node versions * do not use `turbo` for the stable build Can't use it because we don't have a workspace in the stable build. * re-rename CI workflow * encode default engine in relevant `package.json` files * make Node 12 work * increase `node-version` matrix * make release workflows explicit (per engine) * add `Oxide` to workflow name * add integration tests for the `oxide` engine * add integration tests for the `stable` engine * run `oxide` integrations against node `18` * run `stable` integration tests against node 18 We should test node 12 for tailwindcss, but integrations itself can run against a newer version. In fact, we always ran them against node 16. * use `localhost` instead of `0.0.0.0` * ensure `webpack-4` works on Node 18 * run relese scripst directly Instead of going via `npm`. It's a bit nicer and quicker! * drop unused scripts * sync package-lock.json * ensure to generate the plugin list before running `jest` We _could_ use an `npm run pretest`, but then you can't run `jest` directly anymore (which is required for some tools like vscode extensions). * cleanup npm scripts * drop pretend comments * fix typo * add `build:rust` as a pre-jest run script
2023-01-19 17:58:25 +01:00
ENGINE: pkg.tailwindcss.engine,
OXIDE: resolveBoolean(process.env.OXIDE, OXIDE_DEFAULT_ENABLED),
}
export const contextMap = new Map()
export const configContextMap = new Map()
export const contextSourcesMap = new Map()
export const sourceHashMap = new Map()
export const NOT_ON_DEMAND = new String('*')
export const NONE = Symbol('__NONE__')
Separate `stable` and `oxide` engines (#10359) * separate `stable` and `oxide` mode (package.json in this case) * drop `install` script (we use a workspace now) * change required engine to 16 * enable OXIDE by default * ignore generated `oxide` files * splitup package.json scripts into "public" and "private" scripts Not ideal of course, but this should make it a tiny bit easier to know which scripts _you_ as a developer / contributor have to run. * drop `workspaces` from the `stable` engine * drop `oxide` related build files from the `stable` engine * drop `oxide` engine specific dependencies from the `stable` engine * use the `oxide-node-api-shim` for the `stable` engine * add little script to swap the engines * drop `oxide:build` from `turbo` config * configure `ci` for `stable` and `oxide` engines - rename `nodejs.yml` -> `ci.yml` - add `ci-stable.yml` (for stable mode and Node 12) - ensure to use the `stable` engine in the `ci-stable.yml` workflow - drop `oxide:___` specific scripts * rename `release-insiders` to `release-insiders-stable` This way we will be able to remove all files that contain `stable` once we are ready. * rename `release-insiders-oxide` to just `release-insiders` * cleanup insider related workflows * rename `release` -> `release-stable` * rename `release-oxide` -> `release` * change names of release workflows * drop `oxide-` prefix from jobs * inline node versions * do not use `turbo` for the stable build Can't use it because we don't have a workspace in the stable build. * re-rename CI workflow * encode default engine in relevant `package.json` files * make Node 12 work * increase `node-version` matrix * make release workflows explicit (per engine) * add `Oxide` to workflow name * add integration tests for the `oxide` engine * add integration tests for the `stable` engine * run `oxide` integrations against node `18` * run `stable` integration tests against node 18 We should test node 12 for tailwindcss, but integrations itself can run against a newer version. In fact, we always ran them against node 16. * use `localhost` instead of `0.0.0.0` * ensure `webpack-4` works on Node 18 * run relese scripst directly Instead of going via `npm`. It's a bit nicer and quicker! * drop unused scripts * sync package-lock.json * ensure to generate the plugin list before running `jest` We _could_ use an `npm run pretest`, but then you can't run `jest` directly anymore (which is required for some tools like vscode extensions). * cleanup npm scripts * drop pretend comments * fix typo * add `build:rust` as a pre-jest run script
2023-01-19 17:58:25 +01:00
function resolveBoolean(value, defaultValue) {
if (value === undefined) {
return defaultValue
}
if (value === '0' || value === 'false') {
return false
}
return true
}
export function resolveDebug(debug) {
if (debug === undefined) {
return false
}
// Environment variables are strings, so convert to boolean
if (debug === 'true' || debug === '1') {
return true
}
if (debug === 'false' || debug === '0') {
return false
}
// Keep the debug convention into account:
// DEBUG=* -> This enables all debug modes
// DEBUG=projectA,projectB,projectC -> This enables debug for projectA, projectB and projectC
// DEBUG=projectA:* -> This enables all debug modes for projectA (if you have sub-types)
// DEBUG=projectA,-projectB -> This enables debug for projectA and explicitly disables it for projectB
if (debug === '*') {
return true
}
let debuggers = debug.split(',').map((d) => d.split(':')[0])
// Ignoring tailwindcss
if (debuggers.includes('-tailwindcss')) {
return false
}
// Including tailwindcss
if (debuggers.includes('tailwindcss')) {
return true
}
return false
}