Repository navigation
[Bug?]: yarn pack drop executable bits #7310
Description
Self-service
- I'd be willing to implement a fix
Describe the bug
A file named bin/foo has executable bit. Yarn classic pack would preserve this, but Yarn berry 4.18.1 drop this when packing the tarball. This means the published packages contains the file without the executable bit.
To reproduce
I extracted a reproducer into this repository:
https://git.sr.ht/~stacyharper/yarn-pack-reproduce
Given yarn classic is installed in the system yarn-1.22.22.
Run ./reproduce.sh and it will showcase the difference between Yarn classic pack and Yarn berry pack. We can clearly see the change with the permission bits of the bin/foo executable file. Npm also behave like Yarn classic, and preserves the bits.
$ treecat ./
./
├── bin/
│ ├── foo+
│ └
├── package.json:
│ {
│ "name": "reproduce",
│ "version": "1.0.0",
│ "description": "",
│ "main": "index.js",
│ "scripts": {
│ "test": "echo \"Error: no test specified\" && exit 1"
│ },
│ "keywords": [],
│ "type": "commonjs",
│ "files": ["bin"]
│ }
│
├── reproduce.sh+
│ #!/bin/sh -x
│
│ rm -rf ./*.tgz package/ && yarn pack && tar xvf ./*.tgz && ls -ls package/bin
│ echo "HAS EXECUTABLE BIT"
│
│ yarn set version canary
│
│ rm -rf ./*.tgz package/ && yarn pack && tar xvf ./*.tgz && ls -ls package/bin
│ echo "DOES NOT HAVE EXECUTABLE BIT"
│
├── yarn.lock:
│ # THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
│ # yarn lockfile v1
│
│
└
$ ./reproduce.sh
+ rm -rf './*.tgz' package/
+ yarn pack
yarn pack v1.22.22
warning package.json: No license field
warning package.json: No license field
success Wrote tarball to "/home/stacy/tmp/reproduce/reproduce-v1.0.0.tgz".
Done in 0.05s.
+ tar xvf ./reproduce-v1.0.0.tgz
package
package/bin
package/package.json
package/bin/foo
+ ls -ls package/bin
total 0
0 -rwxr-xr-x 1 stacy stacy 0 Oct 20 16:02 foo
+ echo 'HAS EXECUTABLE BIT'
HAS EXECUTABLE BIT
+ yarn set version canary
warning package.json: No license field
➤ YN0000: You don't seem to have Corepack enabled; we'll have to rely on yarnPath instead
➤ YN0000: Downloading https://repo.yarnpkg.com/4.18.1/packages/yarnpkg-cli/bin/yarn.js
➤ YN0000: Saving the new release in .yarn/releases/yarn-4.18.1.cjs
➤ YN0000: Done with warnings in 0s 385ms
+ rm -rf ./reproduce-v1.0.0.tgz package/
+ yarn pack
➤ YN0000: bin/foo
➤ YN0000: package.json
➤ YN0000: Package archive generated in /home/stacy/tmp/reproduce/package.tgz
➤ YN0000: Done in 0s 69ms
+ tar xvf ./package.tgz
package/bin/foo
package/package.json
+ ls -ls package/bin
total 0
0 -rw-r--r-- 1 stacy stacy 0 Jun 22 1984 foo
+ echo 'DOES NOT HAVE EXECUTABLE BIT'
DOES NOT HAVE EXECUTABLE BITEnvironment
System:
OS: Linux 7.2 Alpine Linux
CPU: (24) x64 AMD Ryzen 9 5900X 12-Core Processor
Binaries:
Node: 24.18.1 - /tmp/xfs-c31b4f8d/node
Yarn: 4.18.1 - /tmp/xfs-c31b4f8d/yarn
npm: 12.0.2 - /usr/bin/npm
Deno: 2.7.4 - /usr/bin/denoAdditional context
No response
Activity
chore: simplify compiler wrapping
chore(cli): simplify compiler wrapping
chore(cli): simplify compiler wrapping
chore(cli): simplify compiler wrapping
chore(cli): simplify compiler wrapping
chore(cli): simplify compiler wrapping
shazzark commentedon Oct 25, 2026
I inspected the packing implementation and acceptance tests. genPackStream assigns executable permissions to files declared in bin or publishConfig.executableFiles otherwise, it assigns 0644. An existing test explicitly expects this normalization. Is #7310 requesting a change to that policy, or should this case use the existing manifest opt-in? I will be interested in contributing a focused fix or documentation clarification once the intended behavior is confirmed.
stacyharper commentedon Oct 25, 2026
Npm, Yarn classic, and Pnpm are behaving differently here. I have not found much specification for packing policies. I'd say we should preserve the file permissions bits.
chore(cli): simplify compiler wrapping
chore: switch to pnpm to fix packing
chore: switch to pnpm to fix packing