Packages sometimes fail to install on NPM about uploadthing

[ViableSystemModel]

Reproduced.

Windows 10 Pro 21H1
[email protected]
[email protected] and [email protected]

Got the same error for both versions of npm:

npm ERR! code E404
npm ERR! 404 Not Found - GET https://registry.npmjs.org/@uploadthing%2feslint-config - Not found
npm ERR! 404
npm ERR! 404 '@uploadthing/[email protected]' is not in this registry.
npm ERR! 404
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.

I changed line 22 in ./package.json from:

"@uploadthing/eslint-config": "0.1.0",
to:
"@uploadthing/eslint-config": "file:./common/eslint-config-custom",

That allowed the package to install. But then running npm run build gave the following error:

build
turbo run build

• Packages in scope: @example/appdir, @example/pagedir, @uploadthing/eslint-config, @uploadthing/react, @uploadthing/tsconfig, docs, uploadthing
• Running build in 7 packages
• Remote caching disabled
uploadthing:build: cache miss, executing c55d788e4ca361d5
docs:build: cache miss, executing bf964c276951d810
uploadthing:build: ERROR: command finished with error: exec: "pnpm": executable file not found in %PATH%
exec: "pnpm": executable file not found in %PATH%

Tasks: 0 successful, 2 total
Cached: 0 cached, 2 total
Time: 1.766s

ERROR run failed: command exited (1)

Seems like turbo is seeing pnpm-lock.yaml and pnpm-workspace.yaml and using pnpm as its command, which is a sensible guess. I don't know enough about turborepo to say for sure, but it seems like making this able to build with multiple package managers is going to involve multiple lock files that could fall out of sync with each other. Might be better to just specify that pnpm is mandatory in the README.

[ViableSystemModel]

There's a potentially relevant comment here: vercel/turbo#1630 (comment):

In this scenario you have a pnpm-lock.yaml and a package-lock.json in the root.

No matter what we attempt to detect it will make somebody unhappy. There is no reasonable way for us to ensure that we guess correctly in this situation.

We provide a method to skip that inference by specifying packageManager and no matter what we decide to do, that will be a requirement in this scenario.

I think this means that the only way to support multiple package managers in a turborepo project is:

1. Remove "packageManager": "[email protected]" from your package.json
2. Add package-lock.json, yarn.lock, and pnpm-lock.yaml to your .gitignore
3. Proceed to do the actual testing and debugging to verify your commands all work with each package manager

So.... sounds like sticking with pnpm and closing this issue is the way to go.

[juliusmarminge]

Seems like turbo is seeing pnpm-lock.yaml and pnpm-workspace.yaml and using pnpm as its command

Yes, we use pnpm as our package manager here. You shouldnt use npm or yarn when developing in this repo. I thought the packageManager field restricted this? Of maybe npm doesnt respect that 🙄

We dont have a contributing guide but we probably should add some quick steps on how to get going.

Closing this.