* introduce `public` folder
This can contain all of the `public` functions we want to expose.
This will be a bit nicer for example when you want to use
internal/private functions (we use some in the vscode intellisense
plugin).
* use public `resolveConfig` function
* expose resolveConfig in the root
This will use the resolveConfig we expose from the `public` folder. We
can probably generate these as well.
* make `colors` public
* make `default config` public
* make `default theme` public
* make `create plugin` public
* update to public paths
* remove `@tailwindcss/aspect-ratio` from tests
This should be tested in its own repo instead.
* remove `@tailwindcss/aspect-ratio` as a dependency
* drop `Build` step from CI
The build step is not a prerequisite anymore for running the tests. When
we want to release a new (insiders) release, the `prepublishOnly` step
will be executed for us.
Before this change, it would have been executed twice:
- Once before the tests
- Once before the actual release
* improve paths for caching purposes
* add pretest scrip for generating the plugin list
Now that we can use `SWC`, automatically generating the plugin list
before running the tests is super fast and you don't even have to think
about it anymore!
* setup integration tests
* fix rgb color syntax
* ensure integration tests always exit
If for any reason the integration tests fail, then it will run forever
on CI (~2hours or something). The `--forceExit` is not ideal but it will
prevent long running processes.
* fix incorrect test
We were never properly waiting for the command to finish.
* handle AbortError properly
In CI, when an AbortController gets aborted an error is thrown
(AbortError). If we don't catch it properly then it will "leak" and the
test will fail.
* improve IO functions
* quit integration tests after 10seconds
* only test a few integrations
* test all integrations using matrix
This will cancel other builds when one fails, it will also separate the
output per integration which can be useful especially now that we are
still figuring things out.
* rename `build` to `test`
* add --verbose flag to receive output in the console
* when reading stdout or stderr, wait a certain about to ensure stability
Debouncing for 200ms means that if another message comes in within those
200ms we delay the execution of the callback.
* simplify workflow
* use terminal output instead of disk events
* cache node_modules for integrations
* empty commit, to test cache hits
When you run `npm version`, it also tries to make a git commit and a git
tag. However, we are not doing anything with this and CI doesn't know
who the committer is.
This fails because we usually use node 14 or 16, which has a
package-lock.json version of `2`. However on node 12, this version is
`1`. This means that after an npm install the package-lock.json is
touched and thus `npm version` fails because git is in a dirty
directory.
Adding a `--force` is not ideal, but also not really an issue since the
only thing that could change is the package-lock.json and this is not
published to npm anyways.
* ensure we build before the tests
Our tests require that for now. Will probably improve this in the
future.
* improve insiders version name
This will make it consistent with previously published versions.
* Add coverage and send to Codecov
* Collect coverage with jest
* Add a badge
* Update package.json
* Update .github/workflows/nodejs.yml
* Add retry logic
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
