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

Add --environment flag to dsl/gem commands #979

Merged
merged 2 commits into from
Jun 13, 2022
Merged

Add --environment flag to dsl/gem commands #979

merged 2 commits into from
Jun 13, 2022

Conversation

paracycle
Copy link
Member

Motivation

Fixes #657

Tapioca is primarily a development tool, and thus, should be used to load applications/gems in development mode by default. Up to now, however, we assumed that we could just be not opinionated about this, which led to mismatch between the output of the commands locally and on CI system (which usually run in test environment).

By adding an --environment flag that defaults to development, we can allow users to use the sensible default, but also to override it.

Implementation

Add the flag to dsl and gem commands and set environment variables for RAILS_ENV and RACK_ENV as early as possible with that value.

Tests

Added CLI tests for the default value and supplied value of the environment flag.

@paracycle paracycle requested a review from a team June 13, 2022 20:06
@paracycle paracycle self-assigned this Jun 13, 2022
lib/tapioca/cli.rb Outdated Show resolved Hide resolved
spec/tapioca/cli/dsl_spec.rb Show resolved Hide resolved
@@ -318,9 +333,15 @@ def __print_version
end

no_commands do
sig { returns(T::Boolean) }
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ohh is it working now? Maybe we can move back the methods from cli_helper then?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems to be working just fine. I can make that refactor afterwards, too.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah ok, the runtime is failing because of this: sorbet/sorbet#5786

I'll move it to CliHelper instead.

Tapioca is primarily a development tool, and thus, should be used to
load applications/gems in `development` mode by default. Up to now,
however, we assumed that we could just be not opinionated about this,
which led to mismatch between the output of the commands locally and on
CI system (which usually run in `test` environment).

By adding an `--environment` flag that defaults to `development`, we
can allow users to use the sensible default, but also to override it.
So that we can add a signature to it without having Thor think it is
a command.

Because of: sorbet/sorbet#5786
extend T::Sig
extend T::Helpers

requires_ancestor { Thor }
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why can't it be under cli_helper if we depend on Thor to get the options?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because CliHelper is messed up. It requires Thor::Shell as an ancestor, which doesn't expose options, and we can't change that to Thor since it is included by the base command as well 😱 .

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Urgh alright, let's keep a note that we need to fix this as well 😱

@paracycle paracycle merged commit a1716ce into main Jun 13, 2022
@paracycle paracycle deleted the uk-add-env branch June 13, 2022 22:03
@shopify-shipit shopify-shipit bot temporarily deployed to production July 7, 2022 17:53 Inactive
@ghiculescu
Copy link
Contributor

Tapioca is primarily a development tool, and thus, should be used to load applications/gems in development mode by default

@paracycle I've been thinking about this for a little while, and I wonder why this is the assumption.

I think there's an argument to be made that it should only load gems from your production group by default (or there should be a way to achieve that). This would protect you from writing code that type checks in development, but raises in production, eg. because it references a constant that only exists in dev because it comes from a dev-only gem.

Would love to hear your thoughts on this.

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.

Best practice RAILS_ENV use for --verify
3 participants