Vitest Pros:
* Automated failing test comments on github PRs
* A nice local UI with incremental testing when changing files (`yarn
test:ui`)
* Also nicely supported in all major IDEs, click to run test works (so
we won't miss what we had with jest).
* Works well with ESM
Vitest Cons:
* The ESBuild transformer vitest uses takes a little longer to transform
than our current SWC/jest setup, however, it is possible to setup SWC as
the transformer for vitest as well (though it only does one transform,
so we're paying ~7-10 seconds instead of ~ 2-3 seconds in transform
phase).
* Exposes how slow our tests are (tongue in cheek here)
Welcome to Hypermod! 🚀
This PR introduces the Hypermod Workflow File which connects the
repository to Hypermod.
The workflow will be triggered by Hypermod when a deployment is
requested, which then uses Hypermod CLI to apply automated code
transformations to your source files.
After the transformations is complete, diffs are collected and a pull
request is created.
Please review the changes and merge this PR to connect.
For more information, visit
[Hypermod](https://hypermod.io/docs/installation).
Co-authored-by: Christopher Kolstad <chriswk@fastmail.com>
## About the changes
Currently, we're running against the older version of our UI. When
making changes to it we want to make sure we're testing the current code
**Details in comments**
---------
Co-authored-by: Tymoteusz Czech <2625371+Tymek@users.noreply.github.com>
Coverage has been failing for a while:
https://github.com/Unleash/unleash/actions/workflows/build_coverage.yaml
It looks related to minimatch version:
```
TypeError: /home/runner/work/unleash/unleash/src/lib/util/isDefined.ts: minimatch is not a function
```
Removing `"minimatch": "^10.0.0",` resolution seems to fix it, but it
will likely introduce a security vulnerability error
Works on my machine results:
```shell
Test Suites: 345 passed, 345 total
Tests: 3 skipped, 3119 passed, 3122 total
Snapshots: 110 passed, 110 total
Time: 218.532 s
```
This workflow has been disabled for a long time and caused confusion the
other day with Melinda while trying to debug some documentation issue.
Now documentation is published by vercel
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
|
[akhileshns/heroku-deploy](https://redirect.github.com/akhileshns/heroku-deploy)
| action | minor | `v3.13.15` -> `v3.14.15` |
---
### Release Notes
<details>
<summary>akhileshns/heroku-deploy (akhileshns/heroku-deploy)</summary>
###
[`v3.14.15`](https://redirect.github.com/AkhileshNS/heroku-deploy/releases/tag/v3.14.15)
[Compare
Source](https://redirect.github.com/akhileshns/heroku-deploy/compare/v3.13.15...v3.14.15)
- Fix stack issue (courtesy of
[@​sstepanchuk](https://redirect.github.com/sstepanchuk))
- Add dotenv dependency (courtesy of
[@​sstepanchuk](https://redirect.github.com/sstepanchuk))
- Update documentation to more precisely mention that the heroku cli
must be installed
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "after 7pm every weekday,before 5am
every weekday" in timezone Europe/Madrid, Automerge - At any time (no
schedule defined).
🚦 **Automerge**: Enabled.
♻ **Rebasing**: Whenever PR is behind base branch, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/Unleash/unleash).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4xNzYuMiIsInVwZGF0ZWRJblZlciI6IjM5LjE3Ni4yIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJkZXBlbmRlbmNpZXMiXX0=-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
We already have 20.18.1 set as the default in our Dockerfile, but we
override it with an arg from the workflow, so this brings the workflow
up to date with what we use as our default.
Added more tests around specific plans. Also added snapshot as per our
conversation @gastonfournier, but I'm unsure how much value it will give
because it seems that the tests should already catch this using
respondWithValidation and the OpenAPI schema. The problem here is that
empty array is a valid state, so there were no reason for the schema to
break the tests.
Adds a GH action that notifies us that core features were changed. The
action listens on paths in the source code where our client api and
frontend api are located. If there is a change to these files, we add a
comment to the PR to review carefully and add principals and CTO as
reviewers.
Due to our use of docusaurus and the openapi plugin we need to allow
Artistic-2.0, Having read the license, it allows for free use of the
licensed code, provided the license is included when distributing, but
does not require a relicensing of products using the licensed code.
CC BY 4.0 This license lets others distribute, remix, tweak, and build
upon your work, even commercially, as long as they credit you for the
original creation. This is the most accommodating of licenses offered.
Recommended for maximum dissemination and use of licensed material.
- Sounds compatible with us
So, since we updated to build-push-action@v6 we're now getting a nice
summary of the build on the summary page of the action. It pointed out
that we're caching 0% of our docker build. Since we probably change our
own code more often than we change our dependencies, sharing the initial
yarn install step between builds from cache seems to be a good idea.
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
## About the changes
When working with automated changes made by the @gitar-bot , custom
automated changes may be necessary. For example,
- Running lint auto-fixes
- Executing code generation
- Updating test snapshot files
- Running internal tools
Gitar recommends these in a separate CI pipeline. We call this [Gitar
Duet](https://gitar.co/docs/more/custom-automated-changes/), where
custom tools run alongside Gitar’s automated changes.
### Important files
github ci workflow files
## Discussion points
Feel free to update the workflow to modify the autofix steps
