## Description
Reload if server and client versions do not match on patch
## Steps for reproduction
1. click button
2. expect xyz
## Code Review
- [ ] hi @kof, I need you to do
- conceptual review (architecture, feature-correctness)
- detailed review (read every line)
- test it on preview
## 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/blob/main/apps/builder/docs/test-cases.md)
document
- [ ] added tests
- [ ] if any new env variables are added, added them to `.env` file
Added "@webstudio-is/sdk/testing" entry point with jsx utilities to
simplify instances representation.
React is used as runtime, then renderJsx traverse resulting tree and
converts into our data.
Upgraded both tsx and esbuild to the latest version and removed override
for esbuild. As a result we have 5 duplicates of esbuild but they will
go away with time.
## Code Review
Following tests are added
```
Published site
✓ clientOnly === false (30 ms)
✓ clientOnly === true (7 ms)
Builder renderer= canvas | preview
✓ script processing are not applied when clientOnly=true executeScriptOnCanvas=false and renderer=canvas (4 ms)
✓ script processing are not applied when clientOnly=true executeScriptOnCanvas=undefined and renderer=canvas (2 ms)
✓ script processing are not applied when clientOnly=false executeScriptOnCanvas=false and renderer=canvas (4 ms)
✓ script processing are not applied when clientOnly=false executeScriptOnCanvas=undefined and renderer=canvas (5 ms)
✓ script processing are not applied when clientOnly=undefined executeScriptOnCanvas=false and renderer=canvas (7 ms)
✓ script processing are not applied when clientOnly=undefined executeScriptOnCanvas=undefined and renderer=canvas (2 ms)
✓ In preview mode, script processing are applied when clientOnly=true and renderer="preview" and executeScriptOnCanvas=true (3 ms)
✓ In preview mode, script processing are applied when clientOnly=true and renderer="preview" and executeScriptOnCanvas=false (2 ms)
✓ In preview mode, script processing are applied when clientOnly=true and renderer="preview" and executeScriptOnCanvas=undefined (2 ms)
✓ In preview mode, script processing are applied when clientOnly=false and renderer="preview" and executeScriptOnCanvas=true (2 ms)
✓ In preview mode, script processing are applied when clientOnly=false and renderer="preview" and executeScriptOnCanvas=false (2 ms)
✓ In preview mode, script processing are applied when clientOnly=false and renderer="preview" and executeScriptOnCanvas=undefined (2 ms)
✓ In preview mode, script processing are applied when clientOnly=undefined and renderer="preview" and executeScriptOnCanvas=true (2 ms)
✓ In preview mode, script processing are applied when clientOnly=undefined and renderer="preview" and executeScriptOnCanvas=false (2 ms)
✓ In preview mode, script processing are applied when clientOnly=undefined and renderer="preview" and executeScriptOnCanvas=undefined (2 ms)
✓ In preview mode, script processing are applied when clientOnly=true and renderer="canvas" and executeScriptOnCanvas=true (1 ms)
✓ In preview mode, script processing are applied when clientOnly=false and renderer="canvas" and executeScriptOnCanvas=true (3 ms)
✓ In preview mode, script processing are applied when clientOnly=undefined and renderer="canvas" and executeScriptOnCanvas=true (2 ms)
✓ Code change cause scripts to be updated (2 ms)
✓ Placeholder is shown if code is "" (1 ms)
✓ Placeholder is shown if code is " "
```
- [ ] hi @istarkov , I need you to do
- conceptual review (architecture, feature-correctness)
- detailed review (read every line)
- test it on preview
## 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/blob/main/apps/builder/docs/test-cases.md)
document
- [ ] added tests
- [ ] if any new env variables are added, added them to `.env.example`
and the `builder/env-check.js` if mandatory
---------
Co-authored-by: istarkov <istarkov@gmail.com>
- esbuild
- jest
- eslint
- eslint-typescript
Also removed "jest" binary from packages and use the one installed in
the root
and deduplicated all deps (got a little messy recently).
This fixes the issue with eventsource-parser package having source
export condition with different setup.
Now everywhere "webstudio" is used to reference our sources.
Here moved code generation of utilities from saas into sdk.
Now InstanceRoot accepts utils object with these 3 fields
- indexesWithinAncestors,
- executeComputingExpressions,
- executeEffectfulExpression,
Generation utility can be shared between cli and saas to simplify
maintenance.
## Description
npm packages update
## Steps for reproduction
1. click button
2. expect xyz
## Code Review
- [ ] hi @kof, I need you to do
- conceptual review (architecture, feature-correctness)
- detailed review (read every line)
- test it on preview
## 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-builder/blob/main/apps/builder/docs/test-cases.md)
document
- [ ] added tests
- [ ] if any new env variables are added, added them to `.env.example`
and the `builder/env-check.js` if mandatory
Esbuild is not officially supported by jest
and all available packages do not fit all our need.
esbuild-jest we used for a long time have problems too.
The most important one is frigile heuristik to instrument any code with
`ock(` in text. And we have some `pointerLock(` in design-system.
The other problem is instrumentation converts to commonjs and result
goes to esbuild which tries to convert back to esm but with only default
export. So jest fails anywhere we try to import design-system in tests.
The other problem is lack of maintanance and very old packages inside.
Here refactored original package and removed everything we don't need
including mocks instrumentation.
This should fix the build in
https://github.com/webstudio-is/webstudio-builder/pull/1986
```diff
Packages:
- 1924
+ 1782
```
The main reason for this change is the realization that a product needs
some more protection than a typical library. With this change it is
still an Open Source Core, but now corporations can't build on top of it
without contributing back to the OSS community or without buying a
license.
Here added custom condition to jest config to make it load source code
instead of build artifacts.
This means we no longer need to rebuild after changing code in other
package
and we may even no need to generate cjs anymore.
## Description
Release 0.61.0
Npm packages update
## Steps for reproduction
1. click button
2. expect xyz
## Code Review
- [ ] hi @kof, I need you to do
- conceptual review (architecture, feature-correctness)
- detailed review (read every line)
- test it on preview
## 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-builder/blob/main/apps/builder/docs/test-cases.md)
document
- [ ] added tests
- [ ] if any new env variables are added, added them to `.env.example`
and the `builder/env-check.js` if mandatory
## Description
Merge after #1487
## Steps for reproduction
1. click button
2. expect xyz
## Code Review
- [ ] hi @kof, I need you to do
- conceptual review (architecture, feature-correctness)
- detailed review (read every line)
- test it on preview
## 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-builder/blob/main/apps/builder/docs/test-cases.md)
document
- [ ] added tests
- [ ] if any new env variables are added, added them to `.env.example`
and the `builder/env-check.js` if mandatory
## Description
NPM update
## Steps for reproduction
1. click button
2. expect xyz
## Code Review
- [ ] hi @kof, I need you to do
- conceptual review (architecture, feature-correctness)
- detailed review (read every line)
- test it on preview
## 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-builder/blob/main/apps/builder/docs/test-cases.md)
document
- [ ] added tests
- [ ] if any new env variables are added, added them to `.env.example`
and the `builder/env-check.js` if mandatory
- 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
pnpm prevents access to jest and @types/jest from packages so we need to
explicitly install it. Though @types/jest is not officially maintained
and often late for months with new major which bloats node_modules with
two versions of jest transitives.
Here is alternative way to use official types. The only downside is
complains these types has less descriptions.
- [x] - Image optimization component moved into standalone package
- [x] - generate-arg-types moved into standalone package - one issue
with current yarn https://github.com/yarnpkg/yarn/issues/4964 (you need
to delete root node_modules, then yarn and yarn build to make
generate-arg-types to work)
- [x] - move json into `__generated__` folder, (allow import json from
__generated__ folders only)
- [x] - Icons moved all gen into `__generated__`
- [x] - css-data generated content moved to `__generated__`
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.
Our designer bundle heavily bloated with not analyzable commonjs
generated by typescript.
The biggest problem comes from bundled icons library which esbuild
cannot tree shake because of cjs.
Another issue is broken code splitting. Packages in one piece are appear
in chunks and always loaded even with dynamic import and React.lazy.
To solve this I migrated each package to native node es modules.
Storybook and jest work almost without changes. Though it's not possible
to run remix in esm project (while still esm packages can be bundled for
ssr). And as a result designer jest failed because of cjs tests requires
from esm packages. As a solution I generated additional commonjs
artifacts in lib/cjs.
du -ck public/build
2336
1736
The new version got more readable snapshots, no longer depends jsdom and
has much better esm support (will be enabled in next PR).
Had to switch to babel to support typescript, react and esm for now.
Ivan Starkov