Gitignore #1195
Gitignore #1195
Conversation
* 'master' of https://github.com/rails/webpacker: (21 commits) Update Ruby versions on Travis CI (rails#1230) Make rubocop happy Fix asset helper for non-css assets in hmr mode CSP warning for Rails 5.2 use 2 spaces for indentation in template injection Update README.md (rails#1198) Remove duplicate yarn-error.log (rails#1197) 3.2.1 Revert file loader (rails#1196) Update default extensions and move to installer (rails#1181) Gitignore (rails#1195) Update uglify plugin (rails#1194) Fixes Vue root instance initialization (rails#1187) Return false in production environments (rails#1179) Fix url loader doc[ci skip] (rails#1183) Use inject_into_file to support rails 4.2 Update gems and npm deps (rails#1180) asset_pack_path + HMR fix; Closes rails#1171 (rails#1172) enhance CHANGELOG.md (rails#1170) CI against Ruby 2.5.0 ...
| @@ -27,6 +27,9 @@ | |||
| /public/packs | |||
| /public/packs-test | |||
| /node_modules | |||
| yarn-debug.log* | |||
| yarn-error.log* | |||
| .yarn-integrity | |||
There was a problem hiding this comment.
I'm sorry for coming back to this old issue. However, I have a question about the decision to add .yarn-integrity to the gitignore template file.
So, this means that by default user won't be able to turn on integrity check on their remote server as when webpacker runs yarn check --integrity it would fail.
Is this the intended behavior, e.g. is it recommended to not check this file into source control (despite it seems like it should be shared across machine)?
Thank you.
There was a problem hiding this comment.
@sikachu No worries! The reason for this is the integrity file would change between environments since the dependencies vary - development vs production(https://yarnpkg.com/lang/en/docs/cli/install/#toc-yarn-install-production-true-false). So, if you run yarn install in development the integrity file would be different vs NODE_ENV=production yarn install (unless I am mistaken).
There was a problem hiding this comment.
Production:
{
"systemParams": "darwin-x64-57",
"modulesFolders": [
"node_modules"
],
"flags": [
"production"
],
"linkedModules": [
"@rails/webpacker"
],vs
Development:
{
"systemParams": "darwin-x64-57",
"modulesFolders": [
"node_modules"
],
"flags": [],
"linkedModules": [
"@rails/webpacker"
],There was a problem hiding this comment.
Ah, I see. Thank you very much.
Very interesting, as I thought that yarn check --integrity with .yarn-integrity file is the way to check that the package hasn't been tampered with when you try to install the same package on your production server by comparing to what you have locally, but I guess it's already doing that with packages.json?
Anyway, I guess I'll just turn of the check on production server instead of checking this file in then, with the hope that yarn is already doing the right thing. 💯
There was a problem hiding this comment.
Your welcome :)
Yeah, it does that by comparing package.json and yarn.lock file. I guess this check is really helpful in development when you have added some dependencies but forgot to install or using an outdated version as specified in yarn.lock or installed the dependencies in a different environment as the original.
Anyway, I guess I'll just turn off the check on production server instead of checking this file in then, with the hope that yarn is already doing the right thing.
Yeah, you don't need to run this check on production. Haven't run into any problem so far.
Fixes: #1193