## Description
Just another PR to sync tokens, but also I've added a GitHub action that
will automatically keep `figma-design-tokens.ts` up to date in the
`figma-tokens` branch
## Code Review
- [ ] hi @kof, I need you to do
- conceptual review (architecture, feature-correctness)
- [ ] hi @TrySound, I need you to do
- detailed review
## Before requesting a review
- [ ] made a self-review
- [ ] added inline comments where things may be not obvious (the "why",
not "what")
## Before merging
- [ ] tested locally and on preview environment (preview dev login:
5de6)
- [ ] updated [test
cases](https://github.com/webstudio-is/webstudio-designer/blob/main/apps/designer/docs/test-cases.md)
document
- [ ] added tests
- [ ] if any new env variables are added, added them to `.env.example`
and the `designer/env-check.js` if mandatory
Co-authored-by: Oleg Isonen <oleg008@gmail.com>
Co-authored-by: Taylor Nowotny <86495896+taylornowotny@users.noreply.github.com>
Co-authored-by: markxtang <122043657+markxtang@users.noreply.github.com>
Co-authored-by: Bot (build-figma-tokens.yml) <bot@localhost>
- all workspace dependencies are use with `workspace:^` protocol which
on publish is replaced with `^VERSION`. This will let us to upgrade
transitive packages in saas without shaman dancing around package.json
and lockfile.
- publish-to-npm script is replaced with `pnpm -r publish` which
recursively publishes all packages if version does not exist in npm
- dropped yarn lockfile
- setup corepack for pnpm and forbid yarn usage with "engines" field
- converted yarn lockfile into pnpm lockfile with `pnpm import` command
- replaced yarn with pnpm in scripts and github actions, had to use
custom cache to support corepack
This PR is only migration. Will use new pnpm features in other PRs.
```diff
du -ckd1 node_modules (yarn)
- 1125032
du -ckd1 node_modules/.pnpm
+ 857456
```
Install time (including cache downloads) in github actions reduced from
42s to 23s
## Before requesting a review
- [ ] if the PR is WIP - use draft mode
- [ ] made a self-review
- [ ] added inline comments where things may be not obvious (the "why",
not "what")
- [ ] what kind of review is needed?
- [x] conceptual
- [X] detailed
- [ ] with testing
## Test cases
- [ ] step by step interaction description and what is expected to
happen
## Before merging
- [ ] tested locally and on preview environment (preview dev login:
5de6)
- [ ] updated [test
cases](https://github.com/webstudio-is/webstudio-designer/blob/main/apps/designer/docs/test-cases.md)
document
- [ ] added tests
- [ ] if any new env variables are added, added them to `.env.example`
and the `designer/env-check.js` if mandatory
This PR moves most of the Storybook configs into a single, private,
package that can be imported/required by your packages. It aims to keep
the config the same for all of them as much as possible - so, for
example, all of the packages are now using Webpack 5 in their
Storybooks.
This PR builds on top of the work done in
https://github.com/webstudio-is/webstudio-designer/pull/519 and
introduces a root-level storybook that just aggregates all of the
per-package storybooks into one.
This allows you to have a single, convenient, URL to visit and browse
all of those existing storybooks at once. To access this storybook you
need to click on the `Details` link attached to the "Storybook Publish:
!webstudio-is/webstudio-designer" status check.
The current URL from this branch is available
[here](https://638affb61acca1e593c6e558-dksaophpxa.chromatic.com/) so
you can take a look at how this looks in practice.
This publishes all available Storybooks to Chromatic - this happens per
push so you will always be able to check out the current state of things
in those Storybooks.
Since you have a lot of Storybooks... this isn't quite convenient. I
plan to combine all of those Storybooks into a single one (a single
storybook that will reference all of those smaller ones). I'd like to do
that in a follow-up PR though - let's now focus on getting this up and
running.
Current solution often fails with
> You cannot publish over the previously published versions
Here I added small script which compares committed version and version
on npm and publish if do not match.
All scripts are run by turbo. So publishing new package is just changing
package script now.