tailwindcss/package.stable.json

113 lines
3.4 KiB
JSON
Raw Permalink 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
{
"name": "tailwindcss",
2024-01-05 15:30:22 -05:00
"version": "3.4.1",
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
"description": "A utility-first CSS framework for rapidly building custom user interfaces.",
"license": "MIT",
"main": "lib/index.js",
"types": "types/index.d.ts",
"repository": "https://github.com/tailwindlabs/tailwindcss.git",
"bugs": "https://github.com/tailwindlabs/tailwindcss/issues",
"homepage": "https://tailwindcss.com",
"bin": {
"tailwind": "lib/cli.js",
"tailwindcss": "lib/cli.js"
},
"tailwindcss": {
"engine": "stable"
},
"scripts": {
"prebuild": "npm run generate && rimraf lib",
"build": "swc src --out-dir lib --copy-files --config jsc.transform.optimizer.globals.vars.__OXIDE__='\"false\"'",
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
"postbuild": "esbuild lib/cli-peer-dependencies.js --bundle --platform=node --outfile=peers/index.js --define:process.env.CSS_TRANSFORMER_WASM=false",
"rebuild-fixtures": "npm run build && node -r @swc/register scripts/rebuildFixtures.js",
"style": "eslint .",
"pretest": "npm run generate",
"test": "jest",
"test:integrations": "npm run test --prefix ./integrations",
"install:integrations": "node scripts/install-integrations.js",
"generate:plugin-list": "node -r @swc/register scripts/create-plugin-list.js",
"generate:types": "node -r @swc/register scripts/generate-types.js",
"generate": "npm run generate:plugin-list && npm run generate:types",
"release-channel": "node ./scripts/release-channel.js",
"release-notes": "node ./scripts/release-notes.js",
"prepublishOnly": "npm install --force && npm run build"
},
"files": [
"src/*",
"cli/*",
"lib/*",
"peers/*",
"scripts/*.js",
"stubs/*",
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
"nesting/*",
"types/**/*",
"*.d.ts",
"*.css",
"*.js"
],
"devDependencies": {
"@swc/cli": "^0.1.62",
"@swc/core": "^1.3.55",
"@swc/jest": "^0.2.26",
"@swc/register": "^0.1.10",
"autoprefixer": "^10.4.14",
"browserslist": "^4.21.5",
"concurrently": "^8.0.1",
"cssnano": "^6.0.0",
"esbuild": "^0.17.18",
"eslint": "^8.39.0",
"eslint-config-prettier": "^8.8.0",
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
"eslint-plugin-prettier": "^4.2.1",
"jest": "^29.6.0",
"jest-diff": "^29.6.0",
"lightningcss": "1.18.0",
"prettier": "^2.8.8",
"rimraf": "^5.0.0",
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
"source-map-js": "^1.0.2",
"turbo": "^1.9.3"
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
},
"dependencies": {
"@alloc/quick-lru": "^5.2.0",
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
"arg": "^5.0.2",
"chokidar": "^3.5.3",
"didyoumean": "^1.2.2",
"dlv": "^1.1.3",
"fast-glob": "^3.3.0",
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
"glob-parent": "^6.0.2",
"is-glob": "^4.0.3",
"jiti": "^1.19.1",
"lilconfig": "^2.1.0",
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
"micromatch": "^4.0.5",
"normalize-path": "^3.0.0",
"object-hash": "^3.0.0",
"picocolors": "^1.0.0",
"postcss": "^8.4.23",
"postcss-import": "^15.1.0",
"postcss-js": "^4.0.1",
"postcss-load-config": "^4.0.1",
"postcss-nested": "^6.0.1",
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
"postcss-selector-parser": "^6.0.11",
"resolve": "^1.22.2",
"sucrase": "^3.32.0"
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
},
2023-07-13 18:00:48 +02:00
"browserslist": ["> 1%", "not edge <= 18", "not ie 11", "not op_mini all"],
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
"jest": {
"testTimeout": 30000,
2023-07-13 18:00:48 +02:00
"setupFilesAfterEnv": ["<rootDir>/jest/customMatchers.js"],
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
"testPathIgnorePatterns": [
"/node_modules/",
"/integrations/",
"/standalone-cli/",
"\\.test\\.skip\\.js$"
],
2023-07-13 18:00:48 +02:00
"transformIgnorePatterns": ["node_modules/(?!lightningcss)"],
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
"transform": {
"\\.js$": "@swc/jest",
"\\.ts$": "@swc/jest"
}
},
"engines": {
"node": ">=14.0.0"
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
}
}