`yarn install` ignores `files` from local dependencies

[phtrivier]

What is the current behavior?

It seems that yarn install ignores files from package.json of projects that are locally depended on.

If the current behavior is a bug, please provide the steps to reproduce.

Using two simple projects that depends on each other locally:

○ → tree
.
|____project1
| |____bad.js
| |____good.js
| |____package.json
|____project2
| |____package.json

project1 specifies which files should be copied by dependent projects:

// project1/package.json
{
    "name" : "project1",
    "version" : "0.0.1",
    "files" : ["good.js"]
}

project2 depends on project1 locally:

// project2/package.json
{
    "name" : "project2",
    "version" : "0.0.1",
    "dependencies" : {
        "project1" : "file:../project1"
    }
}

npm install in project2 only copies the good file:

 2017-03-02 12:43:41 ⌚  turus in ~/tmp/yarn-issue/project2
○ → npm install
project2@0.0.1 /home/phtrivier/tmp/yarn-issue/project2
└── project1@0.0.1 

npm WARN project2@0.0.1 No description
npm WARN project2@0.0.1 No repository field.
npm WARN project2@0.0.1 No license field.

 2017-03-02 12:43:45 ⌚  turus in ~/tmp/yarn-issue/project2
○ → ll node_modules/project1/
total 32
drwxrwxr-x 2 phtrivier phtrivier 4096 mars   2 12:43 .
drwxrwxr-x 3 phtrivier phtrivier 4096 mars   2 12:43 ..
-rw-rw-r-- 1 phtrivier phtrivier   37 mars   2 12:37 good.js
-rw-rw-r-- 1 phtrivier phtrivier 1171 mars   2 12:43 package.json

However, yarn install copies everything, ignoring files:

  2017-03-02 12:43:48 ⌚  turus in ~/tmp/yarn-issue/project2
○ → rm -rf node_modules

 2017-03-02 12:44:55 ⌚  turus in ~/tmp/yarn-issue/project2
○ → yarn install
yarn install v0.21.3
warning project2@0.0.1: No license field
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
Done in 0.26s.

 2017-03-02 12:44:58 ⌚  turus in ~/tmp/yarn-issue/project2
○ → ll node_modules/project1/
total 44
drwxrwxr-x 2 phtrivier phtrivier 4096 mars   2 12:44 .
drwxrwxr-x 3 phtrivier phtrivier 4096 mars   2 12:44 ..
-rw-rw-r-- 1 phtrivier phtrivier   57 mars   2 12:37 bad.js
-rw-rw-r-- 1 phtrivier phtrivier   37 mars   2 12:37 good.js
-rw-rw-r-- 1 phtrivier phtrivier   80 mars   2 12:38 package.json

 2017-03-02 12:45:03 ⌚  turus in ~/tmp/yarn-issue/project2
○ → 

What is the expected behavior?

Same behavior as npm.

Please mention your node.js, yarn and operating system version.

○ → npm --version
3.10.10
○ → yarn --version
0.21.3
○ → uname -a
Linux turus 4.8.0-39-generic #42-Ubuntu SMP Mon Feb 20 11:47:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

[rally25rs]

I suspect this may be a common error across other resolvers as well.

Normally when you npm publish a package, only the items listed in files are included in the .tgz, so for normal NPM packages, the cli tool (npm or yarn) doesn't have to really worry about it.

(you can verify this by setting up an offline cache directory and yarn add bootstrap, then compare the downloaded .tgz to their GitHub repo. Only the items from files are in the downloaded/cached .tgz, not every file in the Github repo)

For other resolvers, it's going to have to filter on its own. I did a quick search through the yarn source and didn't see anything that would be doing that check (though I could have missed it).

[SimenB]

@rally25rs yarn pack does this filtering to avoid bundling them before publish.

[kohlmannj]

Confirming @rally25rs's suspicion: this issue appears to also affect installation from GitHub using the git+https:// protocol. I've seen Yarn install a private GitHub dependency with its src and build folders, despite its package.json:files array containing only the build folder.

I suppose publishing with yarn pack is the workaround, but that's not feasible for all projects. Ultimately it'd be better to honor the files property.

[foxymoron]

For private git repositories, if npm is able to filter packages by reading the files:[] property, shouldn't yarn be doing the same ?

[MonsieurBon]

We face exactly the same problem with a dependency we're pulling directly out of our private corporate git repository. Any idea when this will be fixed?