You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 17, 2023. It is now read-only.
Since `mv` "deletes" the source file on disk, we have a race condition
where two actors are trying to build the same tarball.
Consider two tasks, t_a and t_b. The optimal happy path looks like
1. t_a runs `npm pack`, creating the tarball in the package dir 2. t_a
runs `mv` to move the tarball into `/dist` 3. t_b sees the tarball in
`/dist` and takes no action
A less happy path can occur, due to the length of time `npm pack`
can take (~1s)
1. t_a runs `npm pack`, creating the tarball in the package dir
2. t_b runs `npm pack`, creating the tarball in the package dir
3. t_a runs `mv` to move the tarball into `/dist`
4. t_b runs `mv` to move the tarball into `/dist` <-- error!
Step 4 here will fail with an error like
```
mv: can't rename 'packages/my-package/scoped-my-package-1.2.3.tgz':
No such file or directory
```
because the first `mv` removes the tarball from disk.
This brings into question the sanity of using a top-level `/dist`
in the first place! Ideally we'd atomically write the tarball into
`/dist` with npm 7's pack-destination[^1], but this flag is not
present in npm 6.
TODO: remove the `/dist` convention all-together
[^1]: https://docs.npmjs.com/cli/v7/commands/npm-pack#pack-destination
0 commit comments