Remove reliance on pnpm

[neubig]

Hi!

I see that we are using pnpm for package management, but it is causing errors on my computer: #819

I'd like to discuss if we really need pnpm. It improves efficiency, but it adds another non-standard dependency for our project (in a project that already has lots of dependencies), and if it may be a source of errors, maybe we can just rely on good-old npm?

What do people think?

[lowlyocean]

FWIW I agree, pnpm causes problem in WSL environments. I needed to work around by editing frontend/.npmrc to have node_linker=hoisted.

In general, this project would take care not to introduce trendy/fashionable solutions to problems that long-standing tools have solved sufficiently. Another example I see of this is Poetry -- until just 3 weeks ago, it wasn't possible to install only-binary packages (which is sometimes necessary , and has been long possible with pip)

[foragerr]

When trying to actively develop on the OpenDevin codebase, switching branches frequently and reinstalling dependencies from scratch; pnpm makes a tangible quality of life improvement over npm, today.

"Today" is key in that statement, at this moment in time pnpm is significantly more performant (both in terms of time cost and storage space) - which is not to say npm wont catch-up, because that's what happened to yarn over time.

I would hope that OpenDevin gets better at it's packaging game (see) so end-users who are just looking to try it out don't have to deal with dev tools.

npm, pip, node even python itself aren't free from installation issues, paths isues and os-compatibility issues.

IMHO, focus effort on improving OpenDevin packaging to insulate end-users from dev-tooling - and let devs optimize dev-tools for dev-efficiency.

[neubig]

I totally get where you're coming from @foragerr .

But even for people who would like to contribute to development, there are people who want to get started developing, get stuck installing software (like pnpm), and then may give up. For instance, I'm spending time resolving errors regarding environment setup now that I could be spending developing something useful.

Unlike a corporate project where it's OK to have assumptions about the user's environment and significant onboarding cost for developers, for open source I think having a low barrier of entry, and compatibility with lots of different environments seems important.

[lowlyocean]

IMHO, focus effort on improving OpenDevin packaging to insulate end-users from dev-tooling - and let devs optimize dev-tools for dev-efficiency.

Generally agree, but an important caveat here is that optimizing dev-tools will often limit the supported dev environments, and that effectively excludes would-be contributors. Another solution is to use Dev containers, where the environment is standardized

So one container for end-users, and another one for devs

[foragerr]

+1 low dev barrier to entry

[lehcode]

I tested NPM, Yarn, and PNPM for building the front end and found PNPM to be the fastest among them all.
Yarn is fast, too, but slightly slower.

PNPM is more than enough for a simple build, and switching to Yarn will provide no obvious profits.
Yarn's advantage is better support for mono repositories with complicated parallel/cacheable builds or cross-app libraries linking.

[neubig]

OK, thanks for the discussion everyone! I think that we'll go ahead with npm to lower the barrier of entry.