studio
studio copied to clipboard
Bump rc-tree from 5.4.3 to 5.7.0
Bumps rc-tree from 5.4.3 to 5.7.0.
Release notes
Sourced from rc-tree's releases.
v5.7.0
- Revert "Revert "fix: disabled draggable node should have draggable className (#632)"" 953d96d
https://github.com/react-component/tree/compare/v5.6.9...v5.7.0
v5.6.9
- Revert "fix: disabled draggable node should have draggable className (#632)" 654edb7
https://github.com/react-component/tree/compare/v5.6.8...v5.6.9
v5.6.8
- v5.6.7 4c3f962
- fix: disabled draggable node should have draggable className (#632) bdfe4b2
https://github.com/react-component/tree/compare/v5.6.7...v5.6.8
v5.6.7
- type: add id prop (#627) 63644b4
- chore(deps-dev): bump
@umijs/fabricfrom 2.12.2 to 3.0.0 (#612) 41721d8https://github.com/react-component/tree/compare/v5.6.6...v5.6.7
v5.6.6
https://github.com/react-component/tree/compare/v5.6.5...v5.6.6
v5.6.5
- fix: Tree should not expand when ctrl key pressed (#595) 2df935f
- Merge branch 'master' of github.com:react-component/tree e580de4
- chore: not allow publish on any branch f80557e
https://github.com/react-component/tree/compare/v5.6.4...v5.6.5
v5.6.4
- chore: More proper ts def (#588) 1c39c28
https://github.com/react-component/tree/compare/v5.6.3...v5.6.4
v5.6.3
https://github.com/react-component/tree/compare/v5.6.2...v5.6.3
v5.6.2
- fix: React 18 StrictMode not work with expand & check (#581) df85155
https://github.com/react-component/tree/compare/v5.6.1...v5.6.2
... (truncated)
Commits
5635072v5.7.0953d96dRevert "Revert "fix: disabled draggable node should have draggable className ...a486403v5.6.9654edb7Revert "fix: disabled draggable node should have draggable className (#632)"b2d382dv5.6.84c3f962v5.6.7bdfe4b2fix: disabled draggable node should have draggable className (#632)63644b4type: add id prop (#627)41721d8chore(deps-dev): bump@umijs/fabricfrom 2.12.2 to 3.0.0 (#612)2ed2c095.6.6- Additional commits viewable in compare view
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
I've enabled yarn berry support on this repo, so if you comment with @dependabot recreate on this PR, it will run with that functionality enabled, however running locally I get the following error:
Syntax Error: Unexpected identifier (Dependabot::SharedHelpers::HelperSubprocessFailed)
(function (exports, require, module, __filename, __dirname) { version https://git-lfs.github.com/spec/v1
^^^^^
SyntaxError: Unexpected identifier
at new Script (node:vm:100:7)
at NativeCompileCache._moduleCompile (/usr/lib/node_modules/corepack/dist/vcc.js:251:18)
at Module._compile (/usr/lib/node_modules/corepack/dist/vcc.js:195:36)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1180:10)
at Module.load (node:internal/modules/cjs/loader:1004:32)
at Function.Module._load (node:internal/modules/cjs/loader:839:12)
at Module.require (node:internal/modules/cjs/loader:1028:19)
at require (/usr/lib/node_modules/corepack/dist/vcc.js:170:20)
at UH (/home/dependabot/.node/corepack/yarn/3.1.0/yarn.js:382:4931)
at mu (/home/dependabot/.node/corepack/yarn/3.1.0/yarn.js:382:5785)
It's not quite clear to me why this is happening, but it occurs while dependabot runs yarn add @actions/[email protected]. The only reference to version https://git-lfs.github.com/spec/v1 I can find in the repo is in some png's.
I am not able to reproduce the issue locally on my mac, but in the image that runs Dependabot I get it consistently when running any yarn command in the repo in question. Next I tried reproducing it in a clean node image:
docker run -it node:16 bash
root@550266554c72:/# git clone https://github.com/foxglove/studio.git
root@550266554c72:/# cd studio/
root@550266554c72:/studio# corepack enable
root@550266554c72:/studio# yarn --version
Syntax Error: Unexpected identifier
(function (exports, require, module, __filename, __dirname) { version https://git-lfs.github.com/spec/v1
^^^^^
SyntaxError: Unexpected identifier
at new Script (node:vm:100:7)
at NativeCompileCache._moduleCompile (/usr/local/lib/node_modules/corepack/dist/vcc.js:251:18)
at Module._compile (/usr/local/lib/node_modules/corepack/dist/vcc.js:195:36)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1180:10)
at Module.load (node:internal/modules/cjs/loader:1004:32)
at Function.Module._load (node:internal/modules/cjs/loader:839:12)
at Module.require (node:internal/modules/cjs/loader:1028:19)
at require (/usr/local/lib/node_modules/corepack/dist/vcc.js:170:20)
at UH (/root/.node/corepack/yarn/3.1.0/yarn.js:382:4931)
at mu (/root/.node/corepack/yarn/3.1.0/yarn.js:382:5785)
So it seems the issue may be related to running yarn on linux for this project? Could it be related to one of the plugins maybe?
@jurre
Thanks for the detailed writeup. I followed your docker instructions and confirmed I saw the same error. It is indeed the plugins which are also stored with lfs.
root@6b529cc4026e:/studio# cat .yarn/plugins/\@yarnpkg/plugin-interactive-tools.cjs
version https://git-lfs.github.com/spec/v1
oid sha256:997be80aa314d2b197c138e29942e61b5fdf264d8d6461853e23485efe1f97c5
size 889645
Do I understand correctly that the container that dependabot runs in does not have git lfs installed?
There is an in-progress PR to automatically install missing plugins during yarn install: https://github.com/yarnpkg/berry/pull/4912 Tho that might not help here if dependabot does not run yarn install before running yarn --version.
How are you handling this for other repos? Or are we alone in tracking these plugin files via lfs?
Will dependabot remain enabled for this repo? We can explore moving these files to regular git tracking and try asking dependabot to recreate this PR.
Do I understand correctly that the container that dependabot runs in does not have git lfs installed?
Yeah that's right
How are you handling this for other repos? Or are we alone in tracking these plugin files via lfs?
I've not seen it before, we see it used for storing large blobs but those are basically never relevant for the dependency updating process. Some background context on this is that prior to yarn berry support, for npm and yarn projects, dependabot would just pull in the package.json / package-lock.json / yarn.lock files and any files they directly require, and use that to perform any updates. Things like plugins etc were previously something that we would ignore entirely, but given Yarn's reliance on it it seems to make sense to pull them in.
The usage of LFS in this case seems a bit out of the ordinary to me, but maybe it's a trend that I've just not seen before? We can enable it, but it would mean having to pull in large files that are most likely not going to be relevant, I think we can only pull all of it in or nothing, so we risk doing unnecessary work that slows down updates 🤔
Will dependabot remain enabled for this repo? We can explore moving these files to regular git tracking and try asking dependabot to recreate this PR.
Up to you, I'm absolutely fine keeping it on for as long as is helpful for y'all 👍
I think we can only pull all of it in or nothing, so we risk doing unnecessary work that slows down updates
It does seem like it's possible to tell lfs to only pull specific files (i.e. things under .yarn): https://github.com/git-lfs/git-lfs/issues/1351#issuecomment-230495709
Up to you, I'm absolutely fine keeping it on for as long as is helpful for y'all
👍 It's definitely helpful for us and we will keep iterating until we get dependabot working. Thank you!
This seems to work:
$ corepack enable
$ apt-get update && apt-get install git-lfs
$ GIT_LFS_SKIP_SMUDGE=1 git clone https://github.com/foxglove/studio.git
$ cd studio
$ git lfs pull --include .yarn
$ yarn --version
3.1.0
The usage of LFS in this case seems a bit out of the ordinary to me,
For some context on why we do this. These plugin files (like the yarn script itself) are typically bundled/built/minified javascript sources. The git diff on these is meaningless for review much like a diff for binary files so there's no value in to us in storing them in a way that makes them diff-able.
While LFS was originally developed as a large file store we have historically used it for binary or compiled files - anywhere where the diff is meaningless and we just need to store the file content.
We currently have 4 plugins. These are their on-disk sizes:
| plugin | size |
|---|---|
| plugin-interactive-tools.cjs | 869k |
| plugin-typescript.cjs | 34k |
| plugin-version.cjs | 1.0M |
| plugin-workspace-tools.cjs | 51K |
So while some are relatively small, you can see that others are not and when we pull in a new version of the larger ones we don't care about storing a diff of them in our history (which similarly bloats the git clone of the repo).
Yeah I can definitely understand the thought behind this, but it doesn't really play nice with our tooling at the moment.
You could consider using gitattributes to hide the diffs by default, but it doesn't help with the repo size.
I've proposed a change to dependabot-core that would run git lfs pull before running yarn: https://github.com/dependabot/dependabot-core/pull/5833
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting @dependabot rebase.
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting @dependabot rebase.
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting @dependabot rebase.
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting @dependabot rebase.
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting @dependabot rebase.
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting @dependabot rebase.
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting @dependabot rebase.
Dependabot tried to update this pull request, but something went wrong. We're looking into it, but in the meantime you can retry the update by commenting @dependabot rebase.
@dependabot recreate
@jurre This has gotten a lot further! ❤️🔥 🎉
However we're still stuck on our CI which runs yarn dedupe --check. It seems like Dependabot doesn't dedupe dependencies (see https://github.com/dependabot/dependabot-core/issues/5830) — any plans to do this? Any known workaround?
@dependabot rebase
@dependabot rebase
@dependabot rebase