jdx / mise

dev tools, env vars, task runner
https://mise.jdx.dev
MIT License
8.03k stars 210 forks source link

yarn set version breaks mise tooling #2322

Open Jesse-Cameron opened 1 week ago

Jesse-Cameron commented 1 week ago

Describe the bug

I've noticed that yarn has introduced a command yarn set version. This allows the yarn version to be controlled internally.

However, this isn't something that mise currently is aware of or can influence sadly. So it can lead to confusing situation where mise thinks the incorrect version is being used.

To Reproduce

In a clean dir:

mise use node@22
mise use yarn@1.22
yarn set version 2
mise current
yarn --version

this should output two differing Expected behavior

I'm not sure how possible this is without digging into the yarn internals. But it would be good if mise was able to coerce yarn into setting the correct version internally? Or perhaps mise could warn that the yarn may not be respecting the version described in .mise.toml?

mise doctor output

version: 2024.6.6 linux-x64 (409d6e4 2024-06-20)
activated: yes
shims_on_path: no

build_info:
  Target: x86_64-unknown-linux-gnu
  Features: DEFAULT, NATIVE_TLS, OPENSSL
  Built: Thu, 20 Jun 2024 16:13:11 +0000
  Rust Version: rustc 1.79.0 (129f3b996 2024-06-10)
  Profile: release

shell:
  /usr/bin/zsh
  zsh 5.8.1 (x86_64-ubuntu-linux-gnu)

dirs:
  data: ~/.local/share/mise
  config: ~/.config/mise
  cache: ~/.cache/mise
  state: ~/.local/state/mise
  shims: ~/.local/share/mise/shims

config_files:
  ~/.tool-versions
  ~/.config/mise/config.toml
  ~/dev/node-test-project/.mise.toml

backends:
  cargo
  core
  go
  npm
  pipx
  spm
  ubi

plugins:
  bun     (core)
  deno    (core)
  erlang  (core)
  go      (core)
  java    (core)
  node    (core)
  python  (core)
  ruby    (core)
  yarn    ssh://git@github.com/mise-plugins/asdf-yarn.git#74ea3b9

toolset:
  node@22.3.0
  yarn@1.22.22
  ruby@3.1.3
  go@1.20

env_vars:
  MISE_SHELL=zsh

settings:
  activate_aggressive = false
  all_compile = false
  always_keep_download = false
  always_keep_install = false
  asdf_compat = false
  cargo_binstall = true
  color = true
  disable_default_shorthands = false
  disable_tools = []
  experimental = false
  go_default_packages_file = "~/.default-go-packages"
  go_download_mirror = "https://dl.google.com/go"
  go_repo = "https://github.com/golang/go"
  go_set_gopath = false
  go_set_goroot = true
  go_skip_checksum = false
  http_timeout = 30
  jobs = 4
  legacy_version_file = false
  legacy_version_file_disable_tools = []
  node_compile = false
  not_found_auto_install = true
  paranoid = false
  plugin_autoupdate_last_check_duration = "7d"
  python_default_packages_file = "/home/jesse/.default-python-packages"
  python_pyenv_repo = "https://github.com/pyenv/pyenv.git"
  raw = false
  trusted_config_paths = []
  quiet = false
  verbose = false
  yes = false
  ci = false
  debug = false
  trace = false
  log_level = "info"
  python_venv_auto_create = false

  [status]
  missing_tools = "if_other_versions_installed"
  show_env = false
  show_tools = false

Additional context Add any other context about the problem here. Consider running mise with --debug or --trace for extra debug info.

roele commented 6 days ago

I am not convinced its a good idea to have mise deal with this since yarn is a community and not a core plugin. I assume that someone who uses this command makes the conscious choice to have the version managed by yarn itself and not mise.

There seem to be various ways the version is set depending on the setup (package.json, yarnPath).

Besides yarn there is also pnpm which version is set by corepack and which can manage node versions itself AFAIK.

jdx commented 5 days ago

yeah I agree with @roele here

Jesse-Cameron commented 21 hours ago

Hi folks,

Thanks for chiming in. Yeah I see your point that managing the version of community tools is a probably a precedent you'd not want to set.

I do wonder if there is space in the mise ls command to warn when the active version isn't what matches the output of yarn|pnpm -v? I just see this as something that may trip a lot of people up.

That said, I appreciate the fine line between managing tool versions and getting caught up in the internals of community tools. So am happy for this to be closed as a 'will not fix'.

Cheers!