-
Notifications
You must be signed in to change notification settings - Fork 4k
Upgrade yarn to latest #9989
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade yarn to latest #9989
Conversation
ae96648 to
d29670a
Compare
| uses: actions/setup-node@v4 | ||
| with: | ||
| node-version-file: ".nvmrc" | ||
| cache: "yarn" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assuming approval works, I will re-enable this cache and clear the caches for actions so that this can replace it and merge. It will be a temporary blocker for people, but one that is easy to fix.
| streamlit_wheel=$(readlink -e "${streamlit_wheel}") | ||
| echo "output_file=${streamlit_wheel}" >> $GITHUB_OUTPUT | ||
| # Build the component lib first so we can use the old version of yarn |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of curiosity, do you know what's the delta for using the new yarn version also in the component-lib module? If it is not big, I think it'd be worth it to do the update simultaneously instead of fragmenting the versions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll play a little more today, but I had issues with resolution of dependencies and type checking. Will do a little more exploration today to see if it's possible (Really, we should put this in the monorepo so it can benefit from further optimization from our systems).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got it working, so I upgraded it. Same comment about the cache. I need to break the caches and merge.
| # NOTE: This hook currently does not work on Windows due to "yarn" not being an executable and win32api.CreateProcess | ||
| # turning `subprocess.run(["yarn", "prettier", "--write"])` into a call to `yarn.exe prettier --write` which does not exist | ||
| entry: ./scripts/run_in_subdirectory.py frontend yarn prettier ../.github --write | ||
| entry: ./scripts/run_in_subdirectory.py frontend/app yarn prettier ../../.github --write |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this change here needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yarn is strict on not using scripts in folders that don't have them in dependencies. The frontend directory does not have prettier, but both lib and app do. Since we are applying these on the .github folder (in neither, I just chose one to leverage its prettier).
Future work would be to break out the eslint/prettier logic into another package for reuse.
| # Build frontend into static files faster by setting BUILD_AS_FAST_AS_POSSIBLE=true flag, which disables eslint and typechecking. | ||
| frontend-fast: | ||
| cd frontend/ ; yarn run buildFast | ||
| cd frontend/ ; yarn workspace @streamlit/app buildFast |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please elaborate on why this is now only running for the app workspace?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It actually does it already. I just simplified it to clean up the scripts in the main frontend package.json https://github.com/streamlit/streamlit/blob/develop/frontend/package.json#L13
| update_files(NODE_ROOT, semver_version) | ||
| update_files(NODE_APP, semver_version) | ||
| update_files(NODE_LIB, semver_version) | ||
| update_files(NODE_APP_ST_LIB, semver_version) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this not needed anymore in the update_version.py script? Also, it looks like we can remove the NODE_APP_ST_LIB variable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yarn workspaces reference each other, so this will now references the library in the workspace https://github.com/streamlit/streamlit/blob/refactor/upgrade-yarn/frontend/app/package.json#L30
which does not change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There seems to be a lot of changes in the NOTICES file (~5k additions, 18k deletions). Do you know what causes this big difference?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah the biggest difference was that we didn't include transitive dependencies. But I got it working! The numbers should be more reasonable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now it seems that the NOTICES file mostly has deletions (8k lines). Have you checked a couple deleted samples if these are expected?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll take a look. Likely it's due to the fact that Vite (and associated libraries) has been moved dev dependencies and that removes items from the NOTICES. But I'll double check.
frontend/package.json
Outdated
| "build": "yarn workspace @streamlit/lib build && yarn workspace @streamlit/app build", | ||
| "buildFast": "yarn workspace @streamlit/app buildFast", | ||
| "buildLib": "yarn workspace @streamlit/lib build", | ||
| "buildLibProd": "yarn workspace @streamlit/lib build:prod", | ||
| "buildApp": "yarn workspace @streamlit/app build", | ||
| "typecheck": "yarn workspace @streamlit/lib typecheck && yarn workspace @streamlit/app typecheck", | ||
| "lint": "yarn lintApp && yarn lintLib", | ||
| "lintApp": "yarn workspace @streamlit/app lint", | ||
| "lintLib": "yarn workspace @streamlit/lib lint", | ||
| "format": "prettier --write --config .prettierrc './{app,lib}/src/**/*.{js,ts,jsx,tsx}'", | ||
| "formatCheck": "prettier --check --config .prettierrc './{app,lib}/src/**/*.{js,ts,jsx,tsx}'", | ||
| "lint:interactive": "yarn eslint-interactive ./app/src ./lib/src", | ||
| "test": "yarn workspace @streamlit/lib test && yarn workspace @streamlit/app test", | ||
| "testcoverage": "yarn workspace @streamlit/lib test --coverage && yarn workspace @streamlit/app test --coverage", | ||
| "testLib": "yarn workspace @streamlit/lib testWatch", | ||
| "testApp": "yarn workspace @streamlit/app testWatch" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these scripts mostly removed as a cleanup, or is there also a technical issue related to this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I thought it would be better to just use the syntax for people and thought this would be a reset. Especially cause you can run tests on all workspaces etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I think I haven't been using these commands in a longer time. Previously, I sometimes used testLib and testApp form the frontend folder but since migrating to vite I have been running all tests just in the VS Code test explorer.
21f7118 to
a348776
Compare
This reverts commit a348776c5aa8c8b7f9cc55b2f8376ae36cf83841.
7289a9a to
7751b27
Compare
lukasmasuch
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🚀
| - name: Build Package | ||
| timeout-minutes: 120 | ||
| run: make package | ||
| run: BUILD_AS_FAST_AS_POSSIBLE=1 make package |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: Is this still an expected change? I believe we removed BUILD_AS_FAST_AS_POSSIBLE
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, this may have been a merge issue. I'll double-check and remove.
.github/workflows/js-tests.yml
Outdated
| - name: Enable and Prepare Latest Yarn | ||
| run: | | ||
| corepack enable | ||
| corepack prepare yarn@4 --activate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: Do we need to specify the exact version of yarn 4 in this command? We have the expected yarn version listed in frontend/package.json, I wonder if they should match here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point! I lean towards making the package manager in package.json more generic (yarn@4) to help identify issues as they come up with new releases/fixes. Does that work with you, or do you feel like having more consistent version/reliable builds more value here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should stick to a specific version since it ensures reproducibility across builds and environments. Helps remove one potential root cause of "works on my machine." 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. I'll update it accordingly.
sfc-gh-bnisco
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! 🚀
## Describe your changes Upgrade yarn to yarn berry. In order to do this we had to do the following: 1. Support yarn licenses in our checker 2. Install packages in both directories and run scripts from the specific directory 3. Fixes to enable yarn in GitHub Actions and whatnot. ## Testing Plan - Tests should pass --- **Contribution License Agreement** By submitting this pull request you agree that all contributions to this project are made under the Apache 2.0 license.
Describe your changes
Upgrade yarn to yarn berry. In order to do this we had to do the following:
Testing Plan
Contribution License Agreement
By submitting this pull request you agree that all contributions to this project are made under the Apache 2.0 license.