Official docker image including tooling dependencies required for web workloads

[javiercn]

Describe the Problem

Using NodeJS and similar tools is very common in web projects including the templates that we support out of the box for building single page applications using Angular and React with an ASP.NET Core backend.

Describe the Solution

It will be great if the official images can contain the tools required for supporting building web workloads (essentially node an NPM) or if we can provide an additional official image that includes these tools. For example, a variant mcr.microsoft.com/dotnet/sdk-web so that users in their docker file can do like below

FROM mcr.microsoft.com/dotnet/sdk-web:6.0 AS build
...

Additional Context

Currently, users need to figure out how to build the app and they are forced to update their dockerfile to properly build web projects as follows:

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build-with-spa
RUN bash -E $(curl -fsSL https://deb.nodesource.com/setup_18.x | bash - ); apt install -y nodejs

From build-with-spa as build
...

There are obvious drawbacks to this, as the user needs to figure this out from the docs or by themselves.

[richlander]

Is multi-stage build an option? It looks like you are exploring that in your other issue.

Also, you can do single-stage build but COPY node using a scheme like this: https://github.com/octokit/octokit.net/blob/main/.devcontainer/Dockerfile#L8-L9

[javiercn]

@richlander I am not sure how/if that would work for node, wouldn't that require us to know all the locations the node installer places files?

Also, multi-stage might be an option, but I don't think it should be the default. It drastically changes how the build process works, and just "happens" to work for SPA applications because the SPA framework takes over the build and we merely copy the results to the output folder.

In other cases, like for example, Razor Class Libraries, it will be much harder to integrate third-party tooling as the results of the third-party build are generally consumed by other parts of the MSBuild pipeline and that would potentially force people to write N-Stages to make sure that things are built in the same order they are in a regular build.

That exposes the user to a level of complexity that it is hidden from them on regular builds and even worse, forces us to design the MSBuild pipeline to account for all these possible combinations. (Whenever you need an input from MSBuild to a third-party tool, you need to make sure you have a target that you can call and that does "just that") and so on.

This is why even though multi-stage builds can work in simple scenarios (SPA, where there is barely no interaction with the MSBuild pipeline) but will quickly fall short in other scenarios.

[richlander]

Node images install via tarball, just like .NET. That means that they are installed to a single place.

https://github.com/nodejs/docker-node/blob/f82af606acd44dc6be7fbb2a069922afa32657f3/18/alpine3.15/Dockerfile#L23

Zooming out, I think we should write guidance that we are happy with. That either includes a pattern or a new flavor of images. However, it would be great to see more customer evidence to motivate creating a new image flavor.

[javiercn]

Zooming out, I think we should write guidance that we are happy with. That either includes a pattern or a new flavor of images. However, it would be great to see more customer evidence to motivate creating a new image flavor.

I agree, I just wanted to make sure we had something tracking it so that we can gather customer input and make clear the challenges customer face creating their own approaches. If the final outcome is that we provide guidance (which should always be a first step) that is totally A-okay with me, that said I want to make sure that we can track this for the time being, even if we backlog it.

[richlander]

How about we start with the copy approach I suggested? We could certainly validate that it works.

It is technically inferior to the curl approach I saw you propose but is simpler (IMO) and perhaps more docker-native.

It is technically inferior because you have to download an OS as well.

[mthalman]

@javiercn - Would you be interested in submitting a PR to this repo with a sample that demonstrates the usage of NodeJS within an ASP.NET Core container?

[martinalderson]

Just a real +1 for this issue. We use various node tools for scss compilation etc as part of build and currently we have to include it using apt-get - this almost doubles the build time on CI alone just to install the npm packages. I am sure anyone doing more complex web development with ASP.NET uses some at least node packages. It also doesn't really map with Visual Studio as VS has a lot of support for this now, which made me think I was missing something that there wasn't an image that supports it as a first class "citizen".

We use apt-get btw so we get security updates automatically vs the tarball approach which would require more logic to find the latest minor version and download it, etc.

[JeffSinclair]

+1 from me. This is a common scenario.