release: Implement environment isolation via dependency vendoring

[aviatesk]

This commit introduces a release process that isolates JETLS's dependencies from packages being analyzed by vendoring them with rewritten UUIDs.

The vendor-deps.jl script automates the entire release process:

1. Fetches clean Project.toml from the development branch
2. Updates and vendors all non-stdlib, non-JLL dependencies
3. Rewrites UUIDs deterministically using uuid5
4. Updates Project.toml with vendored dependencies and [sources] entries

This approach ensures JETLS's dependencies never conflict with packages users are analyzing, resolving issues where version conflicts between JETLS and analyzed packages would prevent analysis.

---

The following describes the current release process using the above script (at least until JETLS has an official release process).

Fow now, we employ the following branch strategy:

• Development branch (master): Regular development with normal UUIDs
• Release branch (release): Vendored dependencies with rewritten UUIDs

Then the release branch is managed as follows:

1. Check out the release branch
2. Merge (not rebase) changes from the development branch: git merge -X theirs master¹
3. Vendor dependency packages: julia vendor-deps.jl --source-branch=master
4. Commit changes
5. Push to remote release

This means users would manually run git pull origin release followed by Pkg.update() to install and update JETLS (this is almost the same as the current process, except that we're pulling from master). However, I may change this distribution method to make it easier using Pkg apps.

For detailed consideration of this vendor approach and release process, refer to:

• https://publish.obsidian.md/jetls/work/JETLS/Release+process+for+JETLS+alpha
• https://publish.obsidian.md/jetls/work/JETLS/JETLS+environment+isolation

Footnotes

1. The -X theirs option automatically resolves merge conflicts by preferring the master branch version. This is necessary because Project.toml files are always modified on the release branch (with vendored UUIDs), causing conflicts when merging. Since vendor-deps.jl fetches and overwrites Project.toml from master anyway in step 3, these conflicts can be safely resolved by taking the master version. Using git merge (rather than git rebase) keeps the commit history linear for users who update via git pull. ↩

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 64.23%. Comparing base (8c3e1f6) to head (6310fce).
⚠️ Report is 2 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #314   +/-   ##
=======================================
  Coverage   64.23%   64.23%           
=======================================
  Files          40       40           
  Lines        4214     4214           
=======================================
  Hits         2707     2707           
  Misses       1507     1507           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[aviatesk]

See https://github.com/aviatesk/JETLS.jl/tree/release for the release branch using the proposed release method here.