It seems that how this umbrella gem installs Turbo and Stimulus has been creating some confusion.
From what I understand, when turbo-rails executes its install task, it checks whether the user is using Webpacker or not. After this has been determined, it then either installs the Node package or adds Turbo to the Asset Pipeline depending on the approach being used by the developer.
This in contrast to how stimulus-rails behaves, in which it installs Stimulus to the Asset Pipeline regardless.
I understand that this behavior is specifically what stimulus-rails is for, but the divergence between the two approaches seems to confuse people. As a personal anecdote, I spent some time looking through the gems' source when setting up a new project to make sure I was getting my desired configuration. Given that hotwire-rails is supposed to be an umbrella gem that installs both solutions, I wanted to open an issue to see if the maintainers feel that this would be an appropriate place to perform a similar check to what occurs in turbo-rails.
For example, when running the install task, the task could check what solution the user is using. If the user is using Webpacker, it can add the Node package. If the user is not using Webpacker, it can go ahead and execute stimulus:install as it does now. By keeping this in hotwire-rails, stimulus-rails is kept from being totally redundant.
I know this would likely be a bit of an awkward flow in the organizational structure of the packages, but I feel that it may cut down on conceptual overhead for new adopters to the Hotwire system that haven't been operating within the non-SPA world recently.
stimulus-rails should work like turbo-rails, where if Webpack is detected, we add it via npm instead of the asset pipeline. Please do take a stab at that on that repo 👍
It seems that how this umbrella gem installs Turbo and Stimulus has been creating some confusion.
From what I understand, when
turbo-rails
executes its install task, it checks whether the user is using Webpacker or not. After this has been determined, it then either installs the Node package or adds Turbo to the Asset Pipeline depending on the approach being used by the developer.This in contrast to how
stimulus-rails
behaves, in which it installs Stimulus to the Asset Pipeline regardless.I understand that this behavior is specifically what
stimulus-rails
is for, but the divergence between the two approaches seems to confuse people. As a personal anecdote, I spent some time looking through the gems' source when setting up a new project to make sure I was getting my desired configuration. Given thathotwire-rails
is supposed to be an umbrella gem that installs both solutions, I wanted to open an issue to see if the maintainers feel that this would be an appropriate place to perform a similar check to what occurs inturbo-rails
.For example, when running the install task, the task could check what solution the user is using. If the user is using Webpacker, it can add the Node package. If the user is not using Webpacker, it can go ahead and execute
stimulus:install
as it does now. By keeping this inhotwire-rails
,stimulus-rails
is kept from being totally redundant.I know this would likely be a bit of an awkward flow in the organizational structure of the packages, but I feel that it may cut down on conceptual overhead for new adopters to the Hotwire system that haven't been operating within the non-SPA world recently.