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

Make "webpacker:yarn_install" task env aware #1331

Merged
merged 4 commits into from Dec 3, 2018
Merged

Make "webpacker:yarn_install" task env aware #1331

merged 4 commits into from Dec 3, 2018

Conversation

odlp
Copy link
Contributor

@odlp odlp commented Mar 9, 2018

Addressing #1330, currently when webpacker compiles in a non-production environment it's removing
node_modules which are dev dependencies.

This is problematic on CI for example because these dependencies may be required to run JS unit tests and re-running yarn install is inefficient.

@odlp
Copy link
Contributor Author

odlp commented Mar 9, 2018

It'd be simpler if we can leave yarn to determine what to install, and remove the --production flag all together.

yarn appears to respect NODE_ENV already:

NODE_ENV=development yarn install --silent && ls node_modules | wc -l
# 966

NODE_ENV=production yarn install --silent && ls node_modules | wc -l
# 666

@gauravtiwari
Copy link
Member

Yes, lets remove production flag

@odlp
Copy link
Contributor Author

odlp commented Dec 2, 2018

@gauravtiwari sure, I can update the PR.

I'm assuming we'll want to set NODE_ENV to match RAILS_ENV, if it hasn't be set already, like:

ENV["NODE_ENV"] ||= ENV["RAILS_ENV"]

Let me know if this doesn't match your expectation

@gauravtiwari
Copy link
Member

@odlp Thank you :), no NODE_ENV is already been set to production for all cases except development, which is fine in node.js/webpack world. So, we just have to remove the flag.

Oli Peate and others added 3 commits December 3, 2018 09:43
When webpacker compiles in a non-production environment it's removing
node_modules which are dev dependencies. This is problematic on CI for
example because these dependencies may be required.
This was failing on CI presumably because BUNDLE_GEMFILE was being
lost, causing the 4.2.x Gemfile tests to fail.
If the NODE_ENV is set then Yarn will behave accordingly (e.g. skip
devDependencies if NODE_ENV=production).

Based on discussion:
#1331 (comment)
@odlp
Copy link
Contributor Author

odlp commented Dec 3, 2018

@gauravtiwari PR updated. I ended up removing the --frozen-lockfile flag too, because I don't think this makes any sense in a development context (only production).

If it's still required we can remove the last commit from the PR and still be in a state where Yarn install is environment aware (e.g. install devDependencies in development, not in production).

@@ -30,4 +30,14 @@ def with_rails_env(env)
Rails.env = ActiveSupport::StringInquirer.new(original)
reloaded_config
end

def with_environment(replacement_env)
Copy link
Member

Choose a reason for hiding this comment

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

I think this method and with_rails_env is the same. Could you please reuse it?

Copy link
Contributor Author

@odlp odlp Dec 3, 2018

Choose a reason for hiding this comment

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

I just tried using with_rails_env("test") and with_rails_env("production") but the tests fail:

Failure:
RakeTasksTest#test_rake_webpacker_yarn_install_in_production_environment [/Users/oli/workspace/webpacker/test/rake_tasks_test.rb:45]:
Expected only production dependencies to be installed.
Expected ["right-pad", "left-pad"] to not include "right-pad".

The Rake task uses system, which inherits environment variables from ENV I believe (hence the with_environment helper). system isn't aware of what's set in Rails.env.

Copy link
Member

Choose a reason for hiding this comment

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

Ahh I see, my bad. Please try:

Webpacker.with_node_env("test") do
  #  block
end

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah nice, thanks for the pointer

@gauravtiwari
Copy link
Member

Thanks @odlp nearly there, just one last tweak :)

@gauravtiwari gauravtiwari merged commit 0bef289 into rails:master Dec 3, 2018
KingTiger001 added a commit to KingTiger001/Rails-web-pack-project that referenced this pull request Jan 15, 2023
* Make webpacker:yarn_install task env aware

When webpacker compiles in a non-production environment it's removing
node_modules which are dev dependencies. This is problematic on CI for
example because these dependencies may be required.

* Use alternative to Bundler.with_clean_env

This was failing on CI presumably because BUNDLE_GEMFILE was being
lost, causing the 4.2.x Gemfile tests to fail.

* Remove explicit production flag from Yarn Install task

If the NODE_ENV is set then Yarn will behave accordingly (e.g. skip
devDependencies if NODE_ENV=production).

Based on discussion:
rails/webpacker#1331 (comment)

* Use existing with_node_env helper
smartech7 pushed a commit to smartech7/ruby-webpacker that referenced this pull request Aug 4, 2023
* Make webpacker:yarn_install task env aware

When webpacker compiles in a non-production environment it's removing
node_modules which are dev dependencies. This is problematic on CI for
example because these dependencies may be required.

* Use alternative to Bundler.with_clean_env

This was failing on CI presumably because BUNDLE_GEMFILE was being
lost, causing the 4.2.x Gemfile tests to fail.

* Remove explicit production flag from Yarn Install task

If the NODE_ENV is set then Yarn will behave accordingly (e.g. skip
devDependencies if NODE_ENV=production).

Based on discussion:
rails/webpacker#1331 (comment)

* Use existing with_node_env helper
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants