Webpacker: don't run `yarn check --integrity` on every rails command

[doits]

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]

You can disable that in development.rb.

Just set config.webpacker.check_yarn_integrity = false

[doits]

@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]

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

[gauravtiwari]

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

[ansonhoyt]

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]

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]

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]

Run rm - rf node_modules && yarn

On Wed, 25 Sep 2019, 9:46 aliraxa-max, [e-mail] wrote:

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

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rails/webpacker/issues/1135?email_source=notifications&email_token=AAKRKF5MN3BRC5JLHO32LD3QLMCLXA5CNFSM4EJC6ZLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7QZYQY#issuecomment-534879299,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKRKFZL3D5NR7Q7DB4OUX3QLMCLXANCNFSM4EJC6ZLA
.

[korny]

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]

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]

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]

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]

https://github.com/rails/webpacker/issues/1135#issuecomment-607972113 this worked for me. Thank You @yasirlateef

[peterwillcn]

config.webpacker.check_yarn_integrity = false

[kurko]

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]

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

https://github.com/rails/webpacker/pull/2518

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

[rossta]

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