Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix rails new --dev #38463

Merged
merged 1 commit into from
Feb 16, 2020
Merged

Fix rails new --dev #38463

merged 1 commit into from
Feb 16, 2020

Conversation

jonathanhefner
Copy link
Member

@jonathanhefner jonathanhefner commented Feb 14, 2020

Follow-up to #38429.

Rails::Command.invoke passes arguments through to the appropriate command class. However, some command classes were ignoring those arguments, and instead relying on the contents of ARGV. In particular, RakeCommand expected ARGV to contain the arguments necessary to the Rake task, and no other arguments. This caused the webpacker:install task to fail when the --dev option from rails new --dev remained in ARGV.

This commit changes the relevant command classes to not rely on the previous contents of ARGV. This commit also adds a missing require for use of Kernel#silence_warnings.

Fixes #38459.

@rails-bot rails-bot bot added the railties label Feb 14, 2020
@eugeneius
Copy link
Member

Is it feasible to add test coverage for the ARGV changes? It's not obvious from the diff what the problem was or why this patch solves it.

@jonathanhefner
Copy link
Member Author

@eugeneius Something I considered was clearing ARGV entirely in Rails::Command.invoke. That way, in the future, it would be impossible for commands to accidentally depend on its previous contents.

However, looking at the test failures, it seems like this change has far-reaching implications. I'm not sure if it is a workable solution.

@eugeneius
Copy link
Member

Those test failures are also happening on master, I don't think they're caused by this change:
https://buildkite.com/rails/rails/builds/67011

@jonathanhefner
Copy link
Member Author

@eugeneius 🙏 🙏 🙏 I saw rails/railties/lib/rails/commands/rake/rake_command.rb in the stack trace, and so I just assumed...

Once master is fixed I will trigger another build to test these changes. Do you think I should add the change I mentioned regarding clearing ARGV?

Follow-up to rails#38429.

`Rails::Command.invoke` passes arguments through to the appropriate
command class.  However, some command classes were ignoring those
arguments, and instead relying on the contents of ARGV.  In particular,
RakeCommand expected ARGV to contain the arguments necessary to the Rake
task, and no other arguments.  This caused the `webpacker:install` task
to fail when the `--dev` option from `rails new --dev` remained in ARGV.

This commit changes the relevant command classes to not rely on the
previous contents of ARGV.  This commit also adds a missing `require`
for use of `Kernel#silence_warnings`.

Fixes rails#38459.
@kaspth kaspth merged commit 0cb6c27 into rails:master Feb 16, 2020
@kaspth
Copy link
Contributor

kaspth commented Feb 16, 2020

Cool! Yeah, I'm not quite sure how to test this, I guess we can pass --dev in railties tests?

Clearing ARGV is interesting! It was definitely a nuisance when I wrote all this, so if we can find a standard way to handle it, that would be great 🙏

jonathanhefner added a commit to jonathanhefner/rails that referenced this pull request Feb 18, 2020
Follow-up to rails#38463.

This commit changes additional command classes to not depend on prior
ARGV contents.
jonathanhefner added a commit to jonathanhefner/rails that referenced this pull request Feb 18, 2020
Follow-up to rails#38463.

By isolating ARGV, we guard against commands inadvertently depending on
prior ARGV contents.  Any such command will now behave consistently when
run via `Rails::Command.invoke`, whether coming from the Rails CLI or
from library code.  Likewise, any ARGV mutations done by a command will
not affect code that executes after `Rails::Command.invoke`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Creating an application from local branch of Rails fails.
3 participants