Recently installed cookiecutter-plone-starter frontend make install fails with ENAMETOOLONG

[kenmanheimer]

Frontend make install fails in the yarn install step with an “ENAMETOOLONG” error for the @storybook/react-docgen-typescript-plugin npm module. (The specific module version may be part of the problem: “@npm:1.0.2-canary.6.9d540b91e815f8fc2f8829189deb00553559ff63.0”.)

This problem only happens for me with new cookiecutter-plone-starter installations. It does not happen in my previously established installation, even if I do a make clean first. I suspect the problem is avoided in my prior install due to already having an older version of the problematic npm module, but I’m not familiar enough with the situation to know.

Below is an example failing run. I don’t have a fix or a workaround, and expect this is a complete blocker for anyone newly trying to build the system using cookiecutter-plone-starter

klm@evo:frontend 8$ make install
+ echo 'Install frontend'
Install frontend
+ make omelette
+ '[' '!' -d omelette ']'
+ ln -sf node_modules/@plone/volto omelette
+ make preinstall
++ pwd
+ '[' -f /home/klm/Projects/Servers/configs/Myr/myr-plone/frontend/mrs.developer.json ']'
+ make develop
+ npx -p mrs-developer missdev --config=jsconfig.json --output=addons --fetch-https

Using src/addons
Update paths in jsconfig.json

+ yarn install
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed in 2s 322ms
➤ YN0000: ┌ Fetch step
➤ YN0001: │ Error: @storybook/react-docgen-typescript-plugin@npm:1.0.2-canary.6.9d540b91e815f8fc2f8829189deb00553559ff63.0: ENAMETOOLONG: name too long, copyfile '/home/klm/.yarn/berry/cache/@storybook-react-docgen-typescript-plugin-npm-1.0.2-canary.6.9d540b91e815f8fc2f8829189deb00553559ff63.0-b31cc57c40-8.zip' -> '/home/klm/Projects/Servers/configs/Myr/myr-plone/frontend/.yarn/cache/@storybook-react-docgen-typescript-plugin-npm-1.0.2-canary.6.9d540b91e815f8fc2f8829189deb00553559ff63.0-b31cc57c40-91a3015d38.zip-99a975c54269aeb7.tmp'
➤ YN0000: └ Completed in 0s 829ms
➤ YN0000: Failed with errors in 3s 158ms
make: *** [Makefile:52: install] Error 1

[kenmanheimer]

I tried a fresh installation from scratch and the same problem is happening.

Moreover, I tried copying over the older version of the install and am able to use it to install and build with no problems. This suggests that the fault is with more recent versions of the packages and not with the host environment.

For those are experiencing this problem it's a complete blocker until someone finds a workaround. (Others don't have access to an older version on which to move forwars.)

[stevepiercy]

What instructions did you follow? There are pre-requisites that must be satisfied, and I suspect the instructions you followed are not correct.

FWIW, I ran through the Plone Deployment last night and it worked for me on macOS 10.15.7.

Here's a commit to a PR that shows the output of cookiecutter gh:collective/cookiecutter-plone-starter for me:

https://github.com/plone/training/blob/e3c63669b7a43f1a4fba61763f9cf7a4467afdd3/docs/plone-deployment/new-project.md

Double check your pre-requisites.

https://training.plone.org/plone-deployment/setup.html

Make sure you use Node 16.

nvm install "16"
nvm use

I think anything that says nvm install "lts/*" should be deleted from the training. It installs Node 18 then aliases default to it.

I also had to do a sledgehammer approach, blasting away all my node packages. I forget what I did, but I found a SO post that was helpful for the error message I kept getting.

[kenmanheimer]

What instructions did you follow? There are pre-requisites that must be satisfied, and I suspect the instructions you followed are not correct.

I followed the steps in Install Plone from its packages thoroughly, including the steps in the Pre-requisites for installation section.

FWIW, I ran through the Plone Deployment last night and it worked for me on macOS 10.15.7.

The system on which I'm experiencing this problem is a headless Intel Xeon workstation running Ubuntu linux 20.04 directly. (The system on which I have the less recent installation that works happens to be a DigitalOcean droplet running Ubuntu 22.04 that I am commissioning to use as the new host for my personal website.)

Here's a commit to a PR that shows the output of cookiecutter gh:collective/cookiecutter-plone-starter for me:

https://github.com/plone/training/blob/e3c63669b7a43f1a4fba61763f9cf7a4467afdd3/docs/plone-deployment/new-project.md

Double check your pre-requisites.

I was careful about the nvm steps, and confirmed initially and now again that my system (Ubuntu 20.04) is set to use node 16, specifically v16.19.0.

I wondered whether my python version might be at fault, so ensured that the system default is Python 3.9. That didn't help with a fresh install per the Install Plone from its packages instructions.

https://training.plone.org/plone-deployment/setup.html

Make sure you use Node 16.

nvm install "16"
nvm use

I think anything that says nvm install "lts/*" should be deleted from the training. It installs Node 18 then aliases default to it.

I am trying the https://training.plone.org/plone-deployment, and skipped the nvm install "lts/*" step. As I said, i've confirmed that my environment is set to use node 16, and also Python 3.9. None of this helps, I'm still getting the ENAMETOOLONG error, blocking the frontend install at yarn install.

I also had to do a sledgehammer approach, blasting away all my node packages. I forget what I did, but I found a SO post that was helpful for the error message I kept getting.

My first posting of this message included a bunch of stuff about trying to clear the npm cache (ultimately, npm cache clean --force) without improving the situation. The important thing is what I discovered next.

Looking for yarn problems with ENAMETOOLONG I found these open yarn bug reports, [Bug] ENAMETOOLONG error while adding GitHub repo with a tag #2892 and a more primary one, [Bug] Dependencies with noisy prepare scripts fail to install #1989. It doesn't look like there's a fix for the problem, but it also looks like the problem is not actually a failure of the install, but a misdirected conduct message causing yarn to mistakenly infer that the install failed. That means that the image build and other actions dependent on the results of the yarn install can actually go ahead! I have built the frontend container image based on this premise and it works fine.

So for me, until this yarn bug (or the package that triggers the bug) is rectified I can change the frontend\Makefiles install action yarn install step to instead be yarn install || true.

(There's also a real bug in the image build step, for which I filed cookiecutter-plone-starter bug report #54 and a pull request, [Fix failing make build-image Dockerfile RUN command syntax #55](https://github.com/collective/cookiecutter-plone-starter/pull/55]. From conversation in the bug report it looks like a different fix may be implemented, but people trying to build the image will need to know about the workaround until one of the fixes is propagated.)

You also mentioned that you had to blast away your node packages, I assume to get the installation process to work. All in all, these things need to be shaken out so people can easily install and deploy Plone 6. I'm hoping that this detailed information will help in that effort, and provide info people can use to workaround the obstacles in the meanwhile.

[kenmanheimer]

Looking for yarn problems with ENAMETOOLONG I found these open yarn bug reports, [Bug] ENAMETOOLONG error while adding GitHub repo with a tag #2892 and a more primary one, [Bug] Dependencies with noisy prepare scripts fail to install #1989. It doesn't look like there's a fix for the problem, but it also looks like the problem is not actually a failure of the install, but a misdirected conduct message causing yarn to mistakenly infer that the install failed. That means that the image build and other actions dependent on the results of the yarn install can actually go ahead! I have built the frontend container image based on this premise and it works fine.

So for me, until this yarn bug (or the package that triggers the bug) is rectified I can change the frontend\Makefiles install action yarn install step to instead be yarn install || true.

I was mistaken, the ENAMETOOLONG problem is severe. It prevents the yarn add link step from happening, so you can't add new modules to your frontend container build.

Note that cookiecutter-plone-starter build generated before some date work fine, even if you do a make clean and rebuild from there. You need do a fresh generation of the build hierarchy to see the problem.

[stevepiercy]

Just to save you some time, this is definitely a JS package thing, not a Python thing.

IIRC, I had to uninstall every JS tool, and sometimes that did not work according to the recommended methods, including this one: https://stackoverflow.com/a/45515581/2214933

I am on the same path as you regarding DO. When I get there, I will follow up with my experience.

[kenmanheimer]

Another important data point: I was able to do a fresh install on the host where I did the less recent without the ENAMETOOLONG error. This suggests that the problem is with some pollution in my build environment on the other host, rather than a problem in yarn. More importantly, it suggests that this problem may not occur for others. I will leave this issue open for a bit in case others do encounter the problem, but maybe it can be closed after enough time (maybe a week or two)?

[kenmanheimer]

Actually, it makes more sense to close the issue and let a new one be opened if someone else encounters the problem.