No bun.lock file - causes break in depedencies #9505
Replies: 3 comments 3 replies
-
|
Note This comment was translated by Claude. Thank you for raising an issue. We will investigate into the matter and get back to you as soon as possible. Original ContentThank you for raising an issue. We will investigate into the matter and get back to you as soon as possible. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @oreporan! I'm Dosu and I’m helping the lobe-chat team. You're correct—there is currently no bun.lock or pnpm-lock.yaml committed to the lobe-chat repository. The .gitignore explicitly ignores all lock files, including bun.lock and pnpm-lock.yaml, so they are never tracked in source control. This means builds (especially in Docker or CI) can break due to dependency drift, which is exactly what PR #9389 worked around by pinning a specific dependency version. There is no project-wide documentation or policy about lock file management for Bun or pnpm, and this absence can lead to the kind of instability you've described. Committing a lock file would make builds reproducible and prevent these issues going forward. To reply, just mention @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other |
Beta Was this translation helpful? Give feedback.
-
|
it's not the best practice in our scene. check it here: https://x.com/arvin17x/status/1790948062644572244. Here's the English translation of the complete thread: [1/5] Many people might add a lockfile for stability, but I genuinely believe that not using a lockfile is also a great practice for open-source projects that are committed to long-term maintenance. When not locking and only following SemVer, you can gain the following benefits: [2/5] 1. Automatically enjoy new features: With every installation, dependencies automatically update to the latest version, allowing you to enjoy the newest features from version upgrades. For example, Ant Design's Select component optimized the multi-select style in a certain version update. I didn't even know which specific version made this detail optimization, but in unlocked mode, I automatically received this experience improvement. If it were locked, it would be unlikely to update the lockfile just for this small detail (what if it breaks something else?) [3/5] 2. Eliminate potential security risks by default: If a certain version of a dependency has a CVE vulnerability reported, it's very difficult to be aware of the risk once it's locked (unless the code is hosted on GitHub, which has the ability to scan dependency vulnerabilities). However, without a lock file, automatically updating to the latest version will most likely fix it directly, and as an upstream application, you don't need to be aware of it at all. [4/5] 3. Timely feedback and co-building with upstream dependencies: The dependency supply chain inevitably has various instabilities. Without version locking, I have the ability to identify issues with the latest versions of upstream dependencies at the first moment, and then provide them with immediate bug feedback. Over the past six months or so, I've provided feedback with a total of 10+ issues to upstream dependencies, and I was almost always the first person to report them. This is what I consider a good model for growing together with the community. [5/5] Of course, the key to achieving this is having a comprehensive CI/CD workflow. Currently, we have reached 1,300+ test cases in LobeChat, with core unit test coverage at over 90%. If any dependency acts up and causes problems, we can basically catch it quickly. This is our greatest confidence in not using a lock file. |
Beta Was this translation helpful? Give feedback.
-
|
Seeing as you are listed on github, and also have Again, this build fix being the proof |
Beta Was this translation helpful? Give feedback.
-
|
Our core principle is to use the latest community dependencies whenever possible. The software supply chain is a complex topic, and locking dependencies only prevents our project from quickly keeping up with the community's version evolution. Not locking dependencies allows us to immediately detect incompatibility issues with the community and promptly report issues, for example:
Active maintenance projects will fix these issues in a timely manner. This approach drives community development and ensures our project benefits from the latest features. In addition, npm itself provides semantic locking features ( In my opinion, locked versions are only a local optimal solution for the project, not a global optimal solution for the open-source community. |
Beta Was this translation helpful? Give feedback.
-
|
Additionally, according to semantic version rules, major version updates theoretically always include BREAKING CHANGES, which is where renovate plays a role. When upgrading major versions, testing or simple regression is required. For minor or patch versions, according to semantic versioning rules, these should be backward-compatible upgrades, so we don't need to consider using renovate. During dependency installation ( |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
📦 Platform
Self hosting Docker
📦 Deploymenet mode
server db(lobe-chat-database image)
📌 Version
<1.132.7
💻 Operating System
Other
🌐 Browser
Other
🐛 Bug Description
The fact that you aren't committing a lock file (pnpm or bun.lock) can cause dependencies to break the build, both in docker and just by running:
$ bun run buildWe believe this is what caused your fix-build PR to pin the versions
Having a lock file could avert this and future dependency related issues
📷 Recurrence Steps
Remove the ~ pinning from PR - #9389
Then run
bun i && bun run build🚦 Expected Behavior
No response
📝 Additional Information
No response
Beta Was this translation helpful? Give feedback.
All reactions