wrapper/tailwindcss
1
0
Fork 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions
tailwindcss/package.stable.json

118 lines
3.5 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",
3.3.0
2023-03-27 21:06:58 +02:00
"version": "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
"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",
"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",
fix `stubs` glob in `files` of package.json
2023-03-15 22:31:12 +01:00
"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.59",
"@swc/core": "1.3.24",
"@swc/jest": "0.2.24",
"@swc/register": "0.1.10",
"autoprefixer": "^10.4.13",
Use `Lightning CSS` in the `PostCSS` Plugin (#10399) * bump lightningcss * use `lightningcss` in the main PostCss Plugin * use lightningcss in our custom matchers Now that we are using `lightningcss` and nesting in the new `oxide` engine, the generated output _will_ be different in the majority of test cases. Using a combination of `prettier` and `lightningcss` will make the output consistent. The moment we are fully using the `oxide` engine, we can drop `lightningcss` or `prettier` again to improve the performance of the tests. * update tests to apply `lightningcss` related changes * update changelog * add `lightningcss` and `browserslist` as dev dependencies to stable package.json * only use `lightningcss` in tests (without prettier) We will only fallback to prettier if lightningcss fails somehow. * apply side effect chagnes due to only using lightningcss for tests * make CI happy (integration tests) Apply changes to integration tests now that we are using lightningcss * transform `lightningcss` for Node 12 when running tests * run prettier on failing tests for `toMatchFormattedCss` This will result in better diffs because diffs are typically per block and/or per line. But lightningcss will simplify certain selectors and the diff won't be as clear. We will only apply the prettier formatting for failing tests in the diff view so that diffs are cleaner and we don't pay for the additional prettier calls when tests pass.
2023-01-23 20:44:31 +01:00
"browserslist": "^4.21.4",
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
"concurrently": "^7.5.0",
"cssnano": "^5.1.14",
"esbuild": "^0.16.10",
"eslint": "^8.31.0",
"eslint-config-prettier": "^8.6.0",
"eslint-plugin-prettier": "^4.2.1",
"jest": "^28.1.3",
"jest-diff": "^28.1.3",
Use `Lightning CSS` in the `PostCSS` Plugin (#10399) * bump lightningcss * use `lightningcss` in the main PostCss Plugin * use lightningcss in our custom matchers Now that we are using `lightningcss` and nesting in the new `oxide` engine, the generated output _will_ be different in the majority of test cases. Using a combination of `prettier` and `lightningcss` will make the output consistent. The moment we are fully using the `oxide` engine, we can drop `lightningcss` or `prettier` again to improve the performance of the tests. * update tests to apply `lightningcss` related changes * update changelog * add `lightningcss` and `browserslist` as dev dependencies to stable package.json * only use `lightningcss` in tests (without prettier) We will only fallback to prettier if lightningcss fails somehow. * apply side effect chagnes due to only using lightningcss for tests * make CI happy (integration tests) Apply changes to integration tests now that we are using lightningcss * transform `lightningcss` for Node 12 when running tests * run prettier on failing tests for `toMatchFormattedCss` This will result in better diffs because diffs are typically per block and/or per line. But lightningcss will simplify certain selectors and the diff won't be as clear. We will only apply the prettier formatting for failing tests in the diff view so that diffs are cleaner and we don't pay for the additional prettier calls when tests pass.
2023-01-23 20:44:31 +01:00
"lightningcss": "^1.18.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
"prettier": "^2.8.1",
"rimraf": "^3.0.0",
"source-map-js": "^1.0.2",
"turbo": "^1.6.3"
},
"peerDependencies": {
"postcss": "^8.0.9"
},
"dependencies": {
"arg": "^5.0.2",
"chokidar": "^3.5.3",
"color-name": "^1.1.4",
"didyoumean": "^1.2.2",
"dlv": "^1.1.3",
"fast-glob": "^3.2.12",
"glob-parent": "^6.0.2",
"is-glob": "^4.0.3",
Enable ESM and TS based config files (#10785) * add `jiti` and `detective-typescript` dependencies * use `jiti` and `detective-typescript` Instead of `detective`, this way we will be able to support `tailwind.config.ts` files and `ESM` files. * use `@swc/core` instead of the built-in `babel` form `jiti` * update changelog * add `jiti` and `detective-typescript` dependencies to `stable` * use `sucrase` to transform the configs * add `sucrase` dependency to `stable` engine * make loading the config easier * use abstracted loading config utils * WIP: make `load` related files public API * use new config loader in PostCSS plugin * add list of default config files to look for * cleanup unused arguments * find default config path when using CLI * improve `init` command * make eslint happy * keep all files in `stubs` folder * add `tailwind.config.js` stub file * Initialize PostCSS config using the same format as Tailwind config * Rename config content stubs to config.*.js * Improve option descriptions for init options * Remove unused code, remove `constants` file * Fix TS warning * apply CLI changes to the Oxide version * update `--help` output in CLI tests * WIP: make tests work on CI TODO: Test all combinations of `--full`, `--ts`, `--postcss`, and `--esm`. * wip * remove unused `fs` * Fix init tests Did you know you could pass an empty args to a command? No? Me neither. ¯\_(ツ)_/¯ * bump `napi-derive` * list extensions we are interested in * no-op the `removeFile` if file doesn't exist * ensure all `init` flags work * ensure we cleanup the new files * test ESM/CJS generation based on package.json * remove unnecessary test We are not displaying output in the `--help` anymore based on whether `type: module` is present or not. Therefore this test is unneeded. * only look for `TypeScript` files when the entryFile is `TypeScript` as well * refactor `load` to be `loadConfig` This will allow you to use: ```js import loadConfig from 'tailwindcss/loadConfig' let config = loadConfig("/Users/xyz/projects/my-app/tailwind.config.ts") ``` The `loadConfig` function will return the configuration object based on the given absolute path of a tailwind configuration file. The given path can be a CJS, an ESM or a TS file. * use the `config.full.js` stub instead of the `defaultConfig.stub.js` file The root `defaultConfig` is still there for backwards compatibilty reasons. But the `module.exports = requrie('./config.full.js')` was causing some problems when actually using tailwindcss. So dropped it instead. * apply `load` -> `loadConfig` changes to `Oxide` engine CLI * ensure we write the config file in the Oxide engine * improve type in Oxide engine CLI * catch errors instead of checking if the file exists A little smaller but just for tests so doesn't matter too much here 👍 * ensure we publish the correct stub files --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Nate Moore <nate@natemoo.re> Co-authored-by: Enzo Innocenzi <enzo@innocenzi.dev>
2023-03-15 22:04:18 +01:00
"jiti": "^1.17.2",
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
"lilconfig": "^2.0.6",
"micromatch": "^4.0.5",
"normalize-path": "^3.0.0",
"object-hash": "^3.0.0",
"picocolors": "^1.0.0",
Use `Lightning CSS` in the `PostCSS` Plugin (#10399) * bump lightningcss * use `lightningcss` in the main PostCss Plugin * use lightningcss in our custom matchers Now that we are using `lightningcss` and nesting in the new `oxide` engine, the generated output _will_ be different in the majority of test cases. Using a combination of `prettier` and `lightningcss` will make the output consistent. The moment we are fully using the `oxide` engine, we can drop `lightningcss` or `prettier` again to improve the performance of the tests. * update tests to apply `lightningcss` related changes * update changelog * add `lightningcss` and `browserslist` as dev dependencies to stable package.json * only use `lightningcss` in tests (without prettier) We will only fallback to prettier if lightningcss fails somehow. * apply side effect chagnes due to only using lightningcss for tests * make CI happy (integration tests) Apply changes to integration tests now that we are using lightningcss * transform `lightningcss` for Node 12 when running tests * run prettier on failing tests for `toMatchFormattedCss` This will result in better diffs because diffs are typically per block and/or per line. But lightningcss will simplify certain selectors and the diff won't be as clear. We will only apply the prettier formatting for failing tests in the diff view so that diffs are cleaner and we don't pay for the additional prettier calls when tests pass.
2023-01-23 20:44:31 +01:00
"postcss": "^8.0.9",
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-import": "^14.1.0",
"postcss-js": "^4.0.0",
"postcss-load-config": "^3.1.4",
"postcss-nested": "6.0.0",
"postcss-selector-parser": "^6.0.11",
"postcss-value-parser": "^4.2.0",
"quick-lru": "^5.1.1",
Enable ESM and TS based config files (#10785) * add `jiti` and `detective-typescript` dependencies * use `jiti` and `detective-typescript` Instead of `detective`, this way we will be able to support `tailwind.config.ts` files and `ESM` files. * use `@swc/core` instead of the built-in `babel` form `jiti` * update changelog * add `jiti` and `detective-typescript` dependencies to `stable` * use `sucrase` to transform the configs * add `sucrase` dependency to `stable` engine * make loading the config easier * use abstracted loading config utils * WIP: make `load` related files public API * use new config loader in PostCSS plugin * add list of default config files to look for * cleanup unused arguments * find default config path when using CLI * improve `init` command * make eslint happy * keep all files in `stubs` folder * add `tailwind.config.js` stub file * Initialize PostCSS config using the same format as Tailwind config * Rename config content stubs to config.*.js * Improve option descriptions for init options * Remove unused code, remove `constants` file * Fix TS warning * apply CLI changes to the Oxide version * update `--help` output in CLI tests * WIP: make tests work on CI TODO: Test all combinations of `--full`, `--ts`, `--postcss`, and `--esm`. * wip * remove unused `fs` * Fix init tests Did you know you could pass an empty args to a command? No? Me neither. ¯\_(ツ)_/¯ * bump `napi-derive` * list extensions we are interested in * no-op the `removeFile` if file doesn't exist * ensure all `init` flags work * ensure we cleanup the new files * test ESM/CJS generation based on package.json * remove unnecessary test We are not displaying output in the `--help` anymore based on whether `type: module` is present or not. Therefore this test is unneeded. * only look for `TypeScript` files when the entryFile is `TypeScript` as well * refactor `load` to be `loadConfig` This will allow you to use: ```js import loadConfig from 'tailwindcss/loadConfig' let config = loadConfig("/Users/xyz/projects/my-app/tailwind.config.ts") ``` The `loadConfig` function will return the configuration object based on the given absolute path of a tailwind configuration file. The given path can be a CJS, an ESM or a TS file. * use the `config.full.js` stub instead of the `defaultConfig.stub.js` file The root `defaultConfig` is still there for backwards compatibilty reasons. But the `module.exports = requrie('./config.full.js')` was causing some problems when actually using tailwindcss. So dropped it instead. * apply `load` -> `loadConfig` changes to `Oxide` engine CLI * ensure we write the config file in the Oxide engine * improve type in Oxide engine CLI * catch errors instead of checking if the file exists A little smaller but just for tests so doesn't matter too much here 👍 * ensure we publish the correct stub files --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Nate Moore <nate@natemoo.re> Co-authored-by: Enzo Innocenzi <enzo@innocenzi.dev>
2023-03-15 22:04:18 +01:00
"resolve": "^1.22.1",
"sucrase": "^3.29.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
},
3.3.0
2023-03-27 21:06:58 +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,
3.3.0
2023-03-27 21:06:58 +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$"
],
3.3.0
2023-03-27 21:06:58 +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": ">=12.13.0"
}
}
Reference in a new issue Copy permalink