Repository navigation
docs: Consider caveat for Yarn 2+ and private repos #537
Description
Activity
- addedfeature requestNew feature or request to improve the current logicNew feature or request to improve the current logic
on Jul 11, 2022 Hello @jdeblasse. Thank you for your report. We'll investigate the feature request.
Description:
Consider adding caveat documentation for using Yarn 2+ with private repos in the Advanced usage section. Yarn 2+ ignores both.npmrcand.yarnrcfiles so any auth settings via setup-node are ignored when using Yarn 2+.Basic usage
Per Yarn's docs regarding snake-cased, prefixed vars. Tested and working.
steps: - uses: actions/checkout@v3 - uses: actions/setup-node@v3 with: node-version: '16.x' - name: Install dependencies run: yarn install --immutable env: YARN_NPM_AUTH_TOKEN: ${{ secrets.YARN_TOKEN }}
Scoped usage
Untested code however should work as described.
my-orgshould be replaced by the scoped name. Complex objects can not be set using Yarn's prefixed env vars so this must be done via command line config.steps: - uses: actions/checkout@v3 - uses: actions/setup-node@v3 with: node-version: '16.x' - name: Setup .yarnrc.yml run: | yarn config set npmScopes.my-org.npmRegistryServer "https://github.com/proxy/npm.pkg.github.com/" yarn config set npmScopes.my-org.npmAlwaysAuth true yarn config set npmScopes.my-org.npmAuthToken $NPM_AUTH_TOKEN env: NPM_AUTH_TOKEN: ${{ secrets.YARN_TOKEN }} - name: Install dependencies run: yarn install --immutable
Status update. I do not confirm so far we have a problem with the scoped yarn config.
The scoped package works without issue with npmjs repository without extra configurations https://github.com/akv-demo/setup-node-test/runs/7906221779?check_suite_focus=true
But with the github repository there's an authentication problem.
@jdeblasse
Thanks for your input, you are right: it is confirmed yarn2 must have extra configuration step to access scoped/private registries.
But please share you opinion - why we should add the workaround to the docs instead of creating the proper .yarnrc.yml during the setup action?@dsame No opinion really. If possible, creating the .yarnrc.yml on the fly is, of course, easier for the end user. It would have to merge with any current .yarnrc.yml files that may be present in the repo. The only potential issue I see with this approach is currently, inputs for setup-node include
registry,scopeandtokenas single entries however yarn 2+ allows for multiple-scoped registries. That said, it still seems best to me that setup-node creates/merges the .yarnrc.yml just as it does currently with .npmrc and .yarnrc.The issue is to be closed with PR
Generating the .yarnrc.yml does not seem to be practical solution because of current version yarn is 1 on the image.I close the issue with providing docs
@jdeblasse please feel free to reopen the issue or create new one if the problem still exists- added a commit that references this issue
on Nov 9, 2023
Description:
Consider adding caveat documentation for using Yarn 2+ with private repos in the Advanced usage section. Yarn 2+ ignores both
.npmrcand.yarnrcfiles so any auth settings via setup-node are ignored when using Yarn 2+.Basic usage
Per Yarn's docs regarding snake-cased, prefixed vars. Tested and working.
Scoped usage
Untested code however should work as described.
my-orgshould be replaced by the scoped name. Complex objects can not be set using Yarn's prefixed env vars so this must be done via command line config.