Robin Malfait b1f4da70d1
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 11:58:25 -05:00

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"
}
}