mirror of
https://github.com/tailwindlabs/tailwindcss.git
synced 2025-12-08 21:36:08 +00:00
* 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
27 lines
684 B
JSON
27 lines
684 B
JSON
{
|
|
"name": "@tailwindcss/integrations-webpack-4",
|
|
"private": true,
|
|
"version": "0.0.0",
|
|
"main": "./src/index.js",
|
|
"browser": "./src/index.js",
|
|
"scripts": {
|
|
"build": "webpack --mode=production",
|
|
"dev": "webpack --mode=development --watch",
|
|
"test": "NODE_OPTIONS=--openssl-legacy-provider jest --runInBand --forceExit"
|
|
},
|
|
"jest": {
|
|
"testTimeout": 10000,
|
|
"displayName": "webpack 4",
|
|
"setupFilesAfterEnv": [
|
|
"<rootDir>/../../jest/customMatchers.js"
|
|
]
|
|
},
|
|
"devDependencies": {
|
|
"css-loader": "^5.2.7",
|
|
"mini-css-extract-plugin": "^1.6.2",
|
|
"postcss-loader": "^4.3.0",
|
|
"webpack": "^4.46.0",
|
|
"webpack-cli": "^4.9.2"
|
|
}
|
|
}
|