--experimental flag adds --pre to bundle update causing non-compatible versions of other gems to be installed

[adam12]

Description

This is relevant as of September 12, 2024 where rbs has a pre-release of 3.6.0.dev.1.

Reproduction steps

1. Run ruby-lsp --experimental in a fresh project and observe that the newly created .ruby-lsp/Gemfile.lock has a non-pre release version of rbs.

2. Run ruby-lsp --experimental again and observe that bundle update is run, but a pre-release version of rbs installed and the .ruby-lsp/Gemfile.lock contains that pre-release version.

$ rm -rf .ruby-lsp
$ ruby-lsp --experimental
Ruby LSP> Skipping lockfile copies because there's no top level bundle
Ruby LSP> Running bundle install for the custom bundle. This may take a while...
Ruby LSP> Command: (bundle check || bundle install) 1>&2
Resolving dependencies...
The Gemfile's dependencies are satisfied
^C
$ grep 'rbs' .ruby-lsp/Gemfile.lock
    rbs (3.5.3)
      rbs (>= 3, < 4)
$ ruby-lsp --experimental
Ruby LSP> Skipping lockfile copies because there's no top level bundle
Ruby LSP> Running bundle install for the custom bundle. This may take a while...
Ruby LSP> Command: ((bundle check && bundle update ruby-lsp debug --pre) || bundle install) 1>&2
The Gemfile's dependencies are satisfied
Fetching gem metadata from https://rubygems.org/........
Resolving dependencies...
Resolving dependencies...
Using psych 5.2.0.beta1 (was 5.1.2)
Fetching rbs 3.6.0.dev.1 (was 3.5.3)
Installing rbs 3.6.0.dev.1 (was 3.5.3) with native extensions
Bundler attempted to update ruby-lsp but its version stayed the same
Bundler attempted to update debug but its version stayed the same
Bundle updated!
^C
$ grep 'rbs' .ruby-lsp/Gemfile.lock
    rbs (3.6.0.dev.1)
      rbs (>= 3, < 4)

[st0012]

This was added in #1126 to test experimental features. But I don't think we need this anymore? @vinistock

[adam12]

To clarify, I was using --experimental to "enable" the experimental features, but this was incorrect. It was just by accident that this --experimental flag also revealed the installation of pre-release libraries.

So perhaps if the flag is kept, this is the intended functionality.

[adam12]

If it was kept, any thoughts on renaming --experimental to --pre?

[vinistock]

My original hope with this flag was to have beta or release candidates published, so that marking the VS Code setting of experimental would both enable experimental server features and install a beta/release candidate version.

We ended up never actually using it and the fact that transitive dependencies may end up being upgraded alongside is a big downside. I think we should remove it 👍.