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

don't run yarn check --integrity on every rails command #1135

Closed
doits opened this issue Dec 20, 2017 · 17 comments
Closed

don't run yarn check --integrity on every rails command #1135

doits opened this issue Dec 20, 2017 · 17 comments

Comments

@doits
Copy link
Contributor

doits commented Dec 20, 2017

yarn check --integrity is always run. Even if I do a rails g migration ..., which obviously has nothing to do with yarn.

I benchmarked it and noticed it adds about 400ms delay to such commands in my case, which is huge imo. It should be changed that it only runs when it makes sense to check for it, like when starting up the web server or the webpack-dev-server.

Since I am not familiar with the rails/railtie internals, I don't know if this is possible or how to implement such checks at the right place.

Is this possible? What do you think?

@kriansa
Copy link

kriansa commented Jan 2, 2018

You can disable that in development.rb.

Just set config.webpacker.check_yarn_integrity = false

@doits
Copy link
Contributor Author

doits commented Jan 2, 2018

@kriansa yes, I know this, but this disables it completely. It often saved me already when running bin/webpacker or rails server with outdated deps, so in general it makes sense to have it enabled on development. But not when I run rails g migration, rails routes, ....

@doits
Copy link
Contributor Author

doits commented Jan 22, 2018

Why was this closed? Will/can not be fixed?

@gauravtiwari
Copy link
Member

@doits Oh yes sorry, confused it with silencing yarn.

@ansonhoyt
Copy link

This check also breaks adding webpacker to an existing project if yarn.lock exists. Running rails webpacker:install loads rails, so this initializer tries to fetch :check_yarn_integrity, which loads config/webpacker.yml. However, this doesn't exist until after we run this rake task.

I had a chuckle at the error message suggesting I run rails webpacker:install:

$ bundle exec rails webpacker:install
RAILS_ENV=development environment is not defined in config/webpacker.yml, falling back to production environment
rails aborted!
Webpacker configuration file not found /Users/ahoyt/code/tiu/pd-tracker/config/webpacker.yml. Please run rails webpacker:install Error: No such file or directory @ rb_sysopen - /Users/ahoyt/code/tiu/pd-tracker/config/webpacker.yml

We could update the installation instructions to:

rm yarn.lock
bundle
bundle exec rails webpacker:install

...but that seems hacky. I like the idea of this initializer being smarter. I haven't learned enough about it to suggest how.

@mcmire
Copy link

mcmire commented Jan 11, 2019

I would love to see this revisited. If anything, I feel like yarn.lock should be checked on running rails assets:precompile (and, as mentioned, on running bin/webpack or bin/webpack-dev-server). Otherwise, it doesn't really matter, since Webpack is run in a separate process.

@aliraxa-max
Copy link

How I can resolve this problem,
=> Booting Puma
=> Rails 6.0.0.rc2 application starting in development
=> Run rails server --help for more startup options
error Couldn't find an integrity file
error Found 1 errors.

========================================
Your Yarn packages are out of date!
Please run yarn install --check-files to update.

To disable this check, please change check_yarn_integrity
to false in your webpacker config file (config/webpacker.yml).

yarn check v1.17.3
info Visit https://yarnpkg.com/en/docs/cli/check for documentation about this command.

Exiting

@chiptus
Copy link

chiptus commented Sep 25, 2019 via email

@korny
Copy link

korny commented Oct 13, 2019

This is quite annoying. The check now (since #1774) also runs yarn check --verify-tree, which takes a whooping 2.7s on my system, effectively doubling environment loading time on every rails command:

# check_yarn_integrity: false
$ time rails runner ''

real	0m3.613s
user	0m2.496s
sys	0m0.790s

# check_yarn_integrity: true
$ time rails runner ''

real	0m6.773s
user	0m5.696s
sys	0m1.575s

Like the OP, I would like to keep the check for rails s, but I don't see why it needs to be run for everything else.

@Grunkhead
Copy link

I fixed this by doing the following steps;

I had to create a symlink because the node binary was not found.
sudo ln -s /usr/bin/nodejs /usr/bin/node

Upgrading NodeJS to 13.* (probably swapped the binary path here, symlink might have been overkill).

Updating Yarn, https://yarnpkg.com/en/package/yarn
Refreshing the shell instance.

@DouglasUrner
Copy link

I fixed this by doing the following steps;

I had to create a symlink because the node binary was not found.
sudo ln -s /usr/bin/nodejs /usr/bin/node

Upgrading NodeJS to 13.* (probably swapped the binary path here, symlink might have been overkill).

Updating Yarn, https://yarnpkg.com/en/package/yarn
Refreshing the shell instance.

Hmm, I'm seeing it with Rails 6 and Node 13.6...

@yasirlateef
Copy link

yasirlateef commented Apr 2, 2020

Faced this issues with rails 5.2.3. I was able to fix it with the following:

  1. Upgrade Yarn: curl --compressed -o- -L https://yarnpkg.com/install.sh | bash
  2. remove node_modules and yarn.lock
  3. yarn install

@david-forer
Copy link

#1135 (comment) this worked for me. Thank You @yasirlateef

@peterwillcn
Copy link

config.webpacker.check_yarn_integrity = false

@kurko
Copy link

kurko commented May 1, 2020

An environment variable would be the best approach IMO. That way you can have it true by default when running rails server or similar, and false otherwise. I'm using something like the following in my config/environments/development.rb.

config.webpacker.check_yarn_integrity =
  ENV["CHECK_YARN_INTEGRITY"].nil? ||
    ENV["CHECK_YARN_INTEGRITY"].to_i > 0

In my case, the docker compose config will set it to 0 for the sidekiq container.

@ttilberg
Copy link

ttilberg commented May 8, 2020

This issue got pinged from a mention above, but it's worth pointing out that this might be able to be closed:

#2518

It looks like you can webpacker to help this out (and this can probably be closed).

@rossta
Copy link
Member

rossta commented Aug 28, 2020

@doits Can we close this issue? Fixed in #2518.

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

No branches or pull requests