release: Implement environment isolation via dependency vendoring

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` [^merge-strategy]
3. Vendor dependency packages: `julia vendor-deps.jl --source-branch=master`
4. Commit changes
5. Push to remote `release`

[^merge-strategy]: 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`.

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/JETLS+release+process
- https://publish.obsidian.md/jetls/work/JETLS/LS+environment+isolation

Author: aviatesk

.gitattributes

@@ -0,0 +1 @@
+vendor/** linguist-generated

.gitignore

@@ -1,8 +1,12 @@
 node_modules
 out
+Project.toml.bak
 Manifest.toml
 Manifest-*.toml
 .envrc
 **/.JETLSConfig.toml
 *.vsix
 docs/build/
+
+# The following line is negated on release branches
+/vendor

DEVELOPMENT.md

@@ -209,3 +209,60 @@ supports dynamic/static registration, and if it does, actively opt-in to use it.
 That is, register it via the `client/registerCapability` request in response to
 notifications sent from the client, most likely `InitializedNotification`.
 The `JETLS.register` utility is especially useful for this purpose.
+
+## Release process
+
+JETLS avoids dependency conflicts with packages being analyzed by rewriting the
+UUIDs of its dependencies and vendoring them. This allows JETLS to have its own
+isolated copies of dependencies that won't conflict with the packages users are
+analyzing.
+
+### Branch strategy
+
+- Development branch: `master`
+  - Regular development happens here
+  - Dependencies keep their original UUIDs
+- Release branch: `release`
+  - Distribution branch for users
+  - Dependencies are vendored with rewritten UUIDs
+  - Includes copies of dependency packages in the `vendor/` directory
+
+### Release procedure
+
+1. Check out the `release` branch
+   ```bash
+   git checkout release
+   ```
+
+2. Merge changes from the development branch
+   ```bash
+   git merge -X theirs master
+   ```
+
+3. Vendor dependency packages
+   ```bash
+   julia vendor-deps.jl --source-branch=master
+   ```
+   This script performs the following:
+   - Fetches the latest `Project.toml` from the `master` branch
+   - Backs it up as `Project.toml.bak`
+   - Cleans up `Manifest.toml`
+   - Updates dependencies with `Pkg.update()`
+   - Loads JETLS and collects dependency packages from `Base.loaded_modules`
+   - Copies each package to `vendor/` and rewrites its UUID
+   - Updates `Project.toml` with vendored UUIDs and `[sources]` entries
+
+4. Commit changes
+   ```bash
+   git add -A
+   git commit -m 'release: 2025-11-23'
+   ```
+
+5. Push to remote
+   ```bash
+   git push origin release
+   ```
+
+Note: `vendor-deps.jl` generates UUIDs using `uuid5(original_uuid, "JETLS-vendor")`.
+This is deterministic, so the same vendored UUID is always generated for the same
+original UUID, ensuring consistency across multiple vendoring operations.