Sorry to be slow to get back to you. hmm, interesting - is this problem still present? I am wondering if this might be a bug, but i’d need to get that confirmed.
This error from your earlier-quoted seems pretty straightforward:
It means that your yarn registry is disallowing us access. What access methods are possible and what authentication have you configured to allow our build hosts access to your registry?
Right, the lack of access is something I’ve tried to fix by passing a --registry flag among other things.
I started this post because the YARN_FLAGS environment variable seems to be ignored, which should be apparent from the logs.
I’m not looking for support to fix the 403 error at the moment, I’m trying to understand why YARN_FLAGS is not working.
Hi, @Robin-Hoodie. There is a known bug where if there is more than one value in YARN_FLAGS (meaning, if there is a space in the value) then the environment variable isn’t parsed at all.
For example, this won’t work:
YARN_FLAGS = '--production=false --verbose'
However, either of these will:
YARN_FLAGS = '--production=false'
# or
YARN_FLAGS = '--verbose'
You might see if just the --registry option works (without --ignore-optional). However, it might be necessary to add an = so there is no space like so:
Do we know if the YARN_FLAGS bug has been fixed yet?
I’m finding myself needing to use more than one Yarn flag again
Bonus question:
Is there any way to view the actual yarn install command including its flags in the Deployment logs?
If you can view the actual command being run in the logs, it’s much easier to debug
Hi, I just checked and it appears that the bug is yet to be fixed. Sadly, I don’t have an ETA either.
You could add an environment variable with the name NETLIFY_VERBOSE and value as TRUE. Note that, it would make the log too verbose and might make it difficult to read.
Thank you very much for the PR. The devs have already made a note of it, but I’ll still ping them once again to see if it can be reviewed/shipped sooner. Thank you for your help and patience.
For everyone following this thread, thanks to the awesome contribution by @Robin-Hoodie this has now been fixed in both xenial and focal build images. Example logs for both:
Hi, can you confirm it does work for “–no-ignore-optional”? I specifically need to install “typedoc” as an optional dependency, but then it’s not found, so I think it’s not installed in the first place despite YARN_FLAGS being correctly reckognized.
You’re right, I could palliate this issue temporarily, since it’s a top dependency I can move it to dev deps. But in other scenario I might not be able to do so. I try to introduce a cleaner pattern regarding to deps in my apps:
deps for runtime deps
devDeps for build-time deps
optional for dev tools such as Storybook, Jest, Cypress.
I use this pattern because I think historically NPM package were not designed to have a build-step, since they ran directly on Node.js, so the dependency division has to be questioned in modern apps with a build-step. Putting everything in dev deps is not an optimal practice these days, optional are underused imo.
So publishing a built Storybook nested within a Next.js app requires optional deps for instance.