heroku / heroku/buildpacks-nodejs
yarnpkg executable no longer available after running buildpack
- Dominant language
- Rust
- Stars
- 28
- Forks
- 17
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 14
Description
The old `heroku/nodejs-corepack` buildpack used to expose the `yarnpkg` executable in the `shim` layer:
```
$ ls -l /layers/heroku_nodejs-corepack/shim/bin
total 0
lrwxrwxrwx. 1 cnb cnb 73 Jan 1 1980 yarn -> ../../../heroku_nodejs-engine/dist/lib/node_modules/corepack/dist/yarn.js
lrwxrwxrwx. 1 cnb cnb 76 Jan 1 1980 yarnpkg -> ../../../heroku_nodejs-engine/dist/lib/node_modules/corepack/dist/yarnpkg.js
```
When updating to the latest `buildpacks-nodejs` version, we noticed that corepack is no longer used, and it now creates a `yarn_vendored` layer that only includes the `yarn` executable:
```
$ ls -l /layers/heroku_nodejs/yarn_vendored/bin
total 4
-rwxr-xr-x. 1 cnb cnb 73 Jan 1 1980 yarn
```
This broke some of our old apps that still tried to find the `yarnpkg` executable.
Would it be okay to also add an executable for `yarnpkg` in the `yarn_vendored` layer? I can work on a quick PR if that's the case.
Contributor guide
Research direction
Start by tracing the buildpack code that creates the yarn_vendored layer and its bin contents. Compare the current layer with the old shim behavior described here; done means the layer exposes both yarn and yarnpkg without breaking the existing yarn executable.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- nodejs
- Domain
- build-system
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100