This is a pretty specific question; I searched across the forums and could not find anything that seemed close, but apologies if I missed something.
I’m wondering if there is a part of Glitch’s internals that blocks the installation of local tarballs (e.g. generated through npm pack) with PNPM. Or even something with how paths are configured with PNPM that would prevent that from working.
When I try to use pnpm install {tarball_path.tgz} or pnpm add {tarball_path.tgz}, I always get the same error:
A store server is running. All store manipulations are delegated to it.
ERROR ENOENT: no such file or directory, open '/app/____.tgz'
Verified the path: Using realpath verifies the tarball is located at the same location I am passing to pnpm install. I have tried passing both relative and absolute paths.
Verified permissions: In case this was a permission issue, I even tried chmod 777, but that did not fix it.
Tried a different filename: Tried using {package}.tgz instead of {package}-{semver}.tgz, just in case PNPM doesn’t like digits for some reason
The really bizarre thing is that pnpm install {REMOTE_URL_tarball.tgz} works fine! This is kind of the opposite of what I would normally expect, since installing from a remote URL always seems (to me) less likely to work on a given system than installing from the local filesystem.
Anybody have any ideas? Installing from the URL works for me (for now), but I would love to learn why local installs are failing.
Thanks for the descriptive post! It’s nice to see a well-written question every now and then.
I assume you’ve searched this error on StackOverflow and generally did your homework - we probably have to wait for a Glitch admin to tell us what’s going on.
Thanks, I figured I might as well be as detailed as possible to prevent unnecessary back-and-forth.
And yeah, I’ve already crawled through a bunch of StackOverflow Q&As. Most of what comes up is issues with incorrect “packages” and/or bundling of local dependencies - e.g. someone manually zipped up files and forgot to include package.json , or nested local dependencies - not applicable in my case, especially since the same tarball works just fine when added by URL.
Bumping with some more information - still no luck on my end, but I’ve tried a few more things to rule out more possibilities, and discovered some new error messages.
Broken: Using the "my-package": "file:./local-package" syntax in package.json fails - either
same error (ENOENT), if trying with tarball, or
could not install from [...], does not contain a package.json file if pointing to an unpacked package (and this is completely untrue; it does contain a package.json file.
Broken: Trying to use link instead of install | add. According to the pnpm docs, pnpm install {unpacked_pkg_dir} should act like cd {unpackaged_pkg_dir} && pnpm link && cd .. && pnpm link {pkg_name}, so I thought I would give that a try.
Running pnpm link in the unpacked package directory threw a new interesting error: EACCES: permission denied, mkdir '/opt/nvm/versions/node/v12.0.0/pnpm-global'
For anyone wanting to play around with this, I’ve created a minimal reproducible project you can use. You can run check-tarball to verify the file exists, and install-tarball to see how it fails:
NOTE: /app/detect-is-on-glitch-1.0.1.tgz is the full path, I have already tried pnpm install / pnpm add with that instead of the the relative path, and both fail as well.
That access denied error is kinda intriguing - I get those sort of errors when I try to install node packages on my normal (non-sudo) account. Have you tried emailing Glitch support?
@CarlyRaeJepsenStan I don’t know how I missed looping them in directly! I should have done that from the start. I’ll ping them on this thread, and if they don’t get back, I’ll eventually email them directly. Thanks for the reminder!
@glitch_support Can you please take a look at this thread? I’ve already done a decent amount of research, trial and error, and even have a reproducible environment ready-to-go. Could really use some official guidance. Thanks!
So, the way this works is, there is a file system with all of the modules preinstalled, and installs if needed. What you are trying to do, from what I see, is you are trying to find a file that is not be stored on the file system.
@chessebuilderman I think we are mostly on the same page, yes. I understand that pnpm uses a single shared package cache, but local packages should be compatible with its system (and are advertised by PNPM to be). And my package is on the file system, despite the ENOENT error saying otherwise.
Hi! I tried looking into this to see why you couldn’t install your local package.
So, the aforementioned store server isn’t actually running within your Glitch app container. I’m speculating a bit here, but I suspect that the problem is the store server outside of your app is unable to access the tgz file within your app because the file paths aren’t the same (/app/dependency.tgz doesn’t exist outside of your app container). This is an unavoidable consequence of how we run pnpm.
But I have a workaround! I noticed in your test app that you had uploaded the tarball as an asset, which stores it on our CDN, and you can actually use that asset URL in your package.json:
That should download and install the tarball from the CDN and allow you to use your dependency in your app. You can check out my remix of yours that does this and logs whether the app is running on Glitch on startup.
Yeah, that is kind of what I was afraid of . I was aware that node_modules didn’t actually exist in the same directory, but had assumed it was symlinked on the same disk / volume, not cross-disk / volume (which was a bad assumption for me to make). Your post clears that up, and yes, that makes sense then that it might not be able to access the file across drives, but URL fetches would still work.
I think PNPM made some improvements that might help with this (cross-device links / copies) if you guys upgrade at some point, although I’m not certain (I’m not super experienced with Unix filesystem stuff, tbh).
For anyone curious, the other way I got this working was to simply switch my project to NPM; this makes sense given that NPM does not use the shared store that is volume separated.
To summarize, working options are:
Switch project to NPM using enable-npm, then install tarball with regular NPM syntax (either npm install {tarball_path.tgz}, or manually edit package.json with "package-name": "file:{tarball_path.tgz}" and run install
Or…
Keep using PNPM, but use pnpm install {REMOTE_URL_tarball.tgz}, or in package.json, "package-name": "{REMOTE_URL_tarball.tgz}"
Thanks for following up @Osmose and looking into this! I’ll mark your response as the solution.
. I was aware that