wasp-lang
Support different package managers
Idea: let the user choose their package manager (yarn, npm, or pnpm).
Alternatively, make the choice for them. If we go down this route, let's explore pnpm. It's supposed to be much faster (and perhaps we'll have an easier time parsing and forwarding its output).
Bump, would love to use Bun, would make development speed significantly faster.
CC @Jarred-Sumner
I'd love for this to be implemented. I've integrated my Wasp app into a monorepo using Turbo and pnpm, but I still have to use npm for Wasp 😞
@Genyus @Octember Thanks for voicing your opinion!
We'll see if we can prioritize it :)
Just a note: IIRC, yarn will complain about having packages inside packages (the .wasp/build/x packages inside the user's wider package) and will request for them to be added as package.json#workspaces, which might have ramifications for our dependency handling, as everything will start sharing dependencies (which it wasn't previously).
Just a note: IIRC,
yarnwill complain about having packages inside packages (the.wasp/build/xpackages inside the user's wider package) and will request for them to be added aspackage.json#workspaces, which might have ramifications for our dependency handling, as everything will start sharing dependencies (which it wasn't previously).
Ok good to know! We do also plan to look into npm workspaces, so maybe once we do that, yarn won't have anything to complain about.
as everything will start sharing dependencies (which it wasn't previously).
FYI, we already share a lot (if not most) of the dependencies already (e.g., web-app and server fall back to user's node_modules for some things.
But like Martin said, we need to take care of this first: #1653
That's a good question. I consider that very high in priority because most of our project structure discussions reach a point where we say "we might get that with NPM workspaces, or not, we don't know." And then we can't discuss any ideas beyond that 😄
I consider it a blocker for a lot of stuff we want to explore, but let's see what @Martinsos thinks.
That's a good question. I consider that very high in priority because most of our project structure discussions reach a point where we say "we might get that with NPM workspaces, or not, we don't know." And then we can't discuss any ideas beyond that 😄
I consider it a blocker for a lot of stuff we want to explore, but let's see what @Martinsos thinks.
npm workspaces is certainly pre-1.0, it will be part of improving the project structure. We will define soon at which point we are doing this.