Consider Swapping Default Package Manager from `yarn` to `npm`

[ksylvest]

esbuild / rollup / webpack all use yarn instead of npm as the default package manager:

• https://github.com/rails/jsbundling-rails/blob/main/lib/install/esbuild/install.rb#L5
• https://github.com/rails/jsbundling-rails/blob/main/lib/install/rollup/install.rb#L6
• https://github.com/rails/jsbundling-rails/blob/main/lib/install/webpack/install.rb#L6

Given some of the issue surrounding yarn v1 / v2 (npm install -g yarn still installs v1.22.22), propose swapping the default package manger to just use npm directly since:

1. It removes a dependency on yarn.
2. Avoids the yarn classic vs yarn modern issues.

[j127]

Maybe add a pnpm option to reduce the space taken up on the hard drive?

[Faq]

There is yarn 4 https://yarnpkg.com/getting-started/install

[tomkr4l]

+1 for this. Both jsbundling-rails and cssbundling-rails require npx which is part of npm but not part of yarn.
This caused me some configuration problems with deploying app, which I solved by adding ynpx package.

I think that migration to npm would be better aligned with node ecosystem and be less troublesome.

[ksylvest]

PR: #223

I'm unclear if yarn brings anything to the table not offered by npm and think it makes sense to change the default. It is still relatively straightforward to swap to a different package manager (e.g. yarn, pnpm, etc). This'll only impact the default used to bootstrap projects AFAIK.

[taketo1113]

Since the default package manager in rails/rails (actiontext and actioncable) is yarn, would not changing the default of jsbundling-rails to npm cause lockfile inconsistencies when running rails new --javascript webpack?

For reference, here are the places in rails/rails that depend on yarn:
https://github.com/rails/rails/blob/4c53863e354ad94dbfaf0643d9cdc99393a1a583/actioncable/lib/rails/generators/channel/channel_generator.rb#L79
https://github.com/rails/rails/blob/4c53863e354ad94dbfaf0643d9cdc99393a1a583/actiontext/lib/generators/action_text/install/install_generator.rb#L18

It seems preferable to keep yarn as the default package manager and have jsbundling-rails switch the commands based on whichever package manager the user is actually using.
Would this approach make sense?

[ksylvest]

@taketo1113 I think you are right about that issue. Do you think it'd be preferable to have cor determine a package in the same manner as css-bundling / js-bundling? The logic to replicate is something like

      def install_javascript_dependencies
        say "Installing JavaScript dependencies", :green
        packages = "@rails/actiontext trix"
        case js_tool
        when :bun then run "bun add #{packages}"
        when :npm then run "npm install #{packages}"
        when :pnpm then run "pnpm add #{packages}"
        when :yarn then run "yarn add #{packages}"
        else 
          say "Please copy / paste '@rails/actiontext' and 'trix' as dependencies of package.json"
        end
      end

      def js_tool
        js_tool_by_config || js_tool_by_executable
      end

      def js_tool_by_executable
        %i[ bun pnpm npm yarn ].each do |executable|
          return executable if system "command -v #{executable} > /dev/null"
        end
      end

      def js_tool_by_config
        case
        when file_exists?("bun.lockb")         then :bun
        when file_exists?("bun.lock")          then :bun
        when file_exists?("bun.config.js")     then :bun
        when file_exists?("package-lock.json") then :npm
        when file_exists?("pnpm-lock.yaml")    then :pnpm
        when file_exists?("yarn.lock")         then :yarn
        end
      end

It is a bit strange since the code to (1) determine a JS runtime and (2) run a install command of an NPM package is replicated across a bunch of spots in core + in a handful of separate projects. The best solution might be to have a single source of truth for determining to install packages, but I'm unclear where that'd live outside the current pattern of copy / pasting everything.

ksylvest/rails@cf4fe76

[taketo1113]

@ksylvest Regarding rails/rails, when running rails new there is no lock file present yet, so I don't think it's possible to determine the npm package manager based on the lock file at that stage.
Personally, I think it would be sufficient if the default npm package manager could be changed from yarn to npm.

To specify which npm package manager to use during rails new, an additional option for rails new would likely be required, as mentioned in the comment below:
rails/rails#47416 (comment)

Currently, the --javascript option for rails new corresponds to choosing a JS bundler (bun, webpack, esbuild, rollup):

$ rails new -h
...
  -j, --js,      [--javascript=JAVASCRIPT]                                     # Choose JavaScript approach
                                                                               # Default: importmap
                                                                               # Possible values: importmap, bun, webpack, esbuild, rollup
  -c,            [--css=CSS]                                                   # Choose CSS processor. Check https://github.com/rails/cssbundling-rails for more options
                                                                               # Possible values: tailwind, bootstrap, bulma, postcss, sass

---

On the other hand, for jsbundling-rails, I do think it's useful to switch the npm package manager based on the lock file when running rails javascript:install:[bun|esbuild|rollup|webpack].

The reason is that I use rails javascript:install when upgrading the jsbundling-rails gem.
Running rails javascript:install during an upgrade allows the Procfile.dev and other configuration files to be updated according to the npm package manager currently used in the project.

[taketo1113]

I have created a Pull Request that detects and uses the package manager in the install tasks as well, similar to how it works in the build tasks.

• Detect package manager in install tasks #224

With this change, rails javascript:install:[bun|esbuild|rollup|webpack] should work correctly even when using pnpm or npm instead of yarn.

To detect the package manager, this PR introduces Jsbundling::PackageManager, following the same approach used in rails/rails:

• Detect JS package manager from lockfiles in generators rails#56636