* calculate tag for the release
This is based on the name we use in the version e.g.: `3.2.0-beta.2`. If
no name can be found in the version, we will default to `latest`
* ignore node_modules caching for now
* Update lockfile
* Tweak formatting
* Refactor content path parsing
* Allow resolving content paths relative to the config file
* Include resolved symlinks as additional content paths
* Update changelog
* Work on suite of tests for content resolution
* reformat integration test list
* Move content resolution tests to integration
* Update future and experimental types
Restrict the GitHub token permissions only to just what is required and make them read-only where possible.
Signed-off-by: neilnaveen <42328488+neilnaveen@users.noreply.github.com>
* 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
