NodeJS: Publish mode check limitations

[IEvangelist]

Today, all of the .With*PackageInstallation calls are protected by a check for run mode:

if (!resource.ApplicationBuilder.ExecutionContext.IsPublishMode)

With the idea of building deploy-centric hosting integrations, it would be really useful to not have this limitation. For example, I was trying to evaluate aspire deploy managing the calls to npm ci and npm run build, and I knew there was already a lot of great work here around this—but then I found out it's only for run mode. The fact that it even has a useCI parameter makes me wonder why it's not for publish mode anyway.

Maybe that could be an optional bool as the last parameter, that defaults to the current behavior? I'm not sure how I feel about that, kind of ugly, but really this functionality would be really helpful. As would something like:

.With*RunCommand

where * is the package manager, and again not only for run mode. Ideally, we could chain calls together:

var builder = DistributedApplication.CreateBuilder(args);

builder.AddNpmApp("react", "../react", "dev")    // npm run dev
       .WithNpmPackageInstallation(useCI: true)  // npm ci
       .WithNpmRunCommand("build:prod");         // npm run build:prod
       
// Omitted for brevity.

Anyway, this is kind of where my head is at. I already implemented a version of the WithNpmRunCommand in my Netlify hosting integration.

Disclaimer: I shamelessly reacted to my own discussion (a lot), call be biased. 🤓

[aaronpowell]

It's an interesting idea, pondering where in the lifetime of a CI workflow each of these steps would be taken. As it currently stands, aspire deploy is a pretty opaque workflow, lacking the ability to do things like gated checks around steps of the workflow or provide clear steps in the process on the phases in a CI pipeline for build, package, deploy.

The original design of theses extensions was for the pre-CLI deployment model, aiming to prevent this step happening when you're doing a build of the manifest, so naturally there is some legacy in the way this is designed.

Additionally, the Node.js integration was, from my perspective, designed around publishing a Docker image, and for that, you're more likely to have been doing the npm install as part of the image build, thus negating the need to run npm install on the "host" machine.

So, this brings an architectural question - who is responsible for deployment artifact generation. I think it could be quite validly argued that the steps you are describing here, npm ci and npm run build:prod would actually be something you want to do in the Netlify hosting integration, maybe something like this:

builder.AddNpmApp("myapp", "../path-to-frontend", "dev")
       .WithHttpEndpoint(targetPort: 4321)
       .PublishAsNetlifySite(new NetlifyDeployOptions() 
       { 
           Dir = "dist" // Your build output directory
       }, (IResourceBuilder<NetlifyAppResource> netlifyBuilder) => {
         return netlifyBuilder.WithNpmInstaller().WithPrepackageCommand("build:prod");
       });

That makes it clear that there's a difference between preparing the "built artifacts" for local dev vs deploy.

[IEvangelist]

13 ships soon enough. I could start anyway. Should I create an issue first, or do you want to—and assign it to me? Happy to make this happen.

[aaronpowell]

Probably don't need an issue, but I'll start a branch (hopefully today) that can be the source for the work against 13 so we don't have to have everyone having to create their own nuget.config and such.

[davidfowl]

@aaronpowell hold off on this, we’re trying to design something for this in the core product at the moment.

[aaronpowell]

@aaronpowell hold off on this, we’re trying to design something for this in the core product at the moment.

Which part?

[davidfowl]

We're working through an end to end with the new template react + vite front end and python backend. That will inform some new patterns dotnet/aspire#12265.