Error at build-* except build-kernel

[whitphx]

https://github.com/whitphx/stlite/actions/runs/3187415477

At the build step (for example make mountable at build-mountable), the following error occurred.

cd packages/sharing; \
yarn build
yarn run v1.22.19
$ craco build
(node:2837) [DEP0148] DeprecationWarning: Use of deprecated folder mapping "./" in the "exports" field module resolution of the package at /home/runner/work/stlite/stlite/node_modules/postcss-safe-parser/node_modules/postcss/package.json.
Update this package.json to use a subpath pattern like "./*".
(Use `node --trace-deprecation ...` to show where the warning was created)
Creating an optimized production build...

Treating warnings as errors because process.env.CI = true.
Most CI servers set it automatically.

Failed to compile.

Conflict: Multiple assets emit different content to the same filename pypi/tornado-6.2-py3-none-any.whl

Conflict: Multiple assets emit different content to the same filename pypi/streamlit-1.13.0-py2.py3-none-any.whl


error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
make: *** [Makefile:57: packages/sharing/build/*] Error 1

This occurred for the first time on a release build triggered by a new Git tag even though the previous builds were all successful.

---

Hypothesis

publish-kernel finishes early and @stlite/kernel has been released on the remote NPM repository before build-* steps start. Then inside these steps @stlite/kernel could be fetched both from local and remote, then it causes some confusion.

One question on it is why it occurs even though the document says yarn prefer the local workspace to the remote as below.

If the package manager was to resolve a range that a workspace could satisfy, it will prefer the workspace resolution over the remote resolution if possible. This is the pillar of the monorepo approach: rather than using the remote packages from the registry, your project packages will be interconnected and will use the code stored within your repository.
https://yarnpkg.com/features/workspaces

[whitphx]

Looks like being related to yarnpkg/yarn#6719.
Prerelease versions do not work well with yarn workspace?

-> Probably right.
Not prerelease version worked well: https://github.com/whitphx/stlite/actions/runs/3188213632

---

Supportive info:

When the packages are versioned as prerelease such as 0.10.2-alpha.0, after running yarn install, yarn.lock has been updated with the following diff. This means the prerelease version is not handled by yarn.

+"@stlite/kernel@*":
+  version "0.10.1"
+  resolved "https://registry.yarnpkg.com/@stlite/kernel/-/kernel-0.10.1.tgz#d3edb4e53de7e950b0c1d5296700bee3802b0ee8"
+  integrity sha512-hHQiy+hKYmTvzcNEOgLxJdhQhZowfF1pegy6TIoXZnsuba3xhJMug7P2rumpBXXjlv4mg5jcsVpk2VlwUT/nkg==
+  dependencies:
+    "@jupyterlab/coreutils" "^5.4.2"
+    "@lumino/coreutils" "^1.12.0"
+    form-data-encoder "^2.0.1"
+    streamlit-browser "^1.12.0"
+

---

So, at this point, only we can do is to avoid using prerelease version with Yarn.