Add Yarn and Pnpm workspaces support

[vsantele]

Related to an existing integration?

Yes

Existing integration

Hosting.JavaScript.Extensions

Overview

Currently, the Javascript hosting extension adds support for turbo and nx workspace. This allows a global install step for all apps in the same monorepo and avoids conflicts with multiple concurrent installs, for instance.

Two more kinds of javascript workspace managers could be added with the same principle: Yarn workspace and pnpm workspace.

These two new workspaces are related to a specific package manager. So, creating a new yarn/pnpm workspace could also set the corresponding package manager for all related apps.

For yarn workspace, we could allow focused install but it's probably out of scope of this request and could be added in a follow-up issue/PR.

Usage example

We can reuse the flow of turbo workspace in a apphost without the WithPackageManagerLaunch method.

// Yarn
var yarnWorkspace = builder.AddYarnWorkspaceApp("yarn-demo");

yarnWorkspace.AddApp("yarn-web", filter: "web")
    .WithHttpEndpoint(env: "PORT")
    .WithMappedEndpointPort()
    .WithHttpHealthCheck();

yarnWorkspace.AddApp("yarn-docs", filter: "docs")
    .WithHttpEndpoint(env: "PORT")
    .WithMappedEndpointPort()
    .WithHttpHealthCheck();

// pnpm
var pnpmWorkspace = builder.AddPnpmWorkspaceApp("pnpm-demo");

pnpmWorkspace.AddApp("pnpm-web", filter: "web")
    .WithHttpEndpoint(env: "PORT")
    .WithMappedEndpointPort()
    .WithHttpHealthCheck();

pnpmWorkspace.AddApp("pnpm-docs", filter: "docs")
    .WithHttpEndpoint(env: "PORT")
    .WithMappedEndpointPort()
    .WithHttpHealthCheck();

Breaking change?

No

Alternatives

The main pain point is the concurrent install for each app added in the apphost but sharing the same lock file. An alternative could be to only run the install step for one app and disable it for the others. Or create an external pnpm/yarn install command in the apphost with .WithPnpm(install: false); set for all apps.

Additional context

This issue is related with this discord discussion: https://discord.com/channels/1361488941836140614/1438609740140904448

Help us help you

Yes, I'd like to be assigned to work on this item

[aaronpowell]

With Yarn and Pnpm now being part of the Aspire repo and not the Community Toolkit, would it make more sense for them to be there? Paging @eerhardt

[vsantele]

I have a prototype with an implementation of pnpm and yarn workspace. I'll try to make a PR tomorrow.

There is a support for yarn and pnpm as "package manager" not as "workspace manager" in the aspire repo. In my opinion, if turbo and nx integrations remain in the Community Toolkit, would it be better to implement the pnpm/yarn workspace integration here as well?
The only downside to this is that a yarn/pnpm workspace is tied to the equivalent package manager, so a user will need both integrations, and it would make more sense to add workspace support in the aspire repo. But if a user uses the turbo or nx integration, he will also need both.

I'm thinking out loud here, I'm open to discussion.

[aaronpowell]

The split of interlinked functionality is where I have the concern as well. Turbo and nx are kind of stand-alone tools but they can leverage yarn or pnpm and we have support for that in the toolkit.

[vsantele]

I just opened a draft PR #1110

I think the overall integration could be improved thanks to the recent changes in the JavaScript integration.

In my opinion, the workspace supports could remain here with Turbo and Nx. The official integration could focus on package manager, build support, etc. While the extension could add workspace support. This is not a feature all the devs need.