dotnet publish removes node_nodules - VSTS probs

[alphster]

I'm wondering if there's something we can change here to make the build/release more compatible with VSTS.

I'm simply pulling the GIT, "dotnet restore", "dotnet publish c -release", then copying my files to the artifacts folder. This automatically runs "npm install" as specified in the project.json.

Problem is, in VSTS, we need to bring the node_modules folder along during this step because we don't have a moment during the RELEASE step to rerun npm install again. It will end up including dev dependencies, but i can live with that.

When I copy all the files out of my publish directory, i noticed that "node_modules" was missing. When I run "dotnet publish" without the -c release parameter, it includes the node_modules. I don't think this is something configurable, at least, I don't know where to config it.

To counteract this, i'm grabbing the /node_modules/ folder that is produced by the dotnet publish (a few levels up from the publish folder).

Is there a better way to configure this?

[SteveSandersonMS]

Interesting. I'm not an expert in VSTS so don't know what exactly the -c parameter does (and in particular, why it causes node_modules not to be included). Do you think you could try to track down that info?

But this scenario sounds like it would be no different from anyone deploying any Node application (not just an ASP.NET Core SPA) via VSTS. Is it just that nobody in the world ever wants to use VSTS with Node and so it's just some inherent incompatibility, or might we have not got things configured in the right way?

[alphster]

The -c parameter belongs to "dotnet publish". The recommended approach is in the link below, and i've followed it pretty closely. Unfortunately, I haven't found any info that tells me what -c Release is doing under the hood :) I know it's removing node_modules. I can experiment with this some more and try to find out what's going on here.

https://www.visualstudio.com/en-us/docs/build/apps/aspnet/aspnetcore-to-azure

I guess i'm having trouble envisioning what the other build/release tools are doing and how they are "getting it right".

In VSTS, you want to create one "build" that is reused for multiple environments (dev->qa->prd). The build agent is responsible for that step, not the developers computer. During that build creation, you need dev dependencies, so the agent pulls all the npm pkgs. Following it up with a "dotnet publish -c Release" removes the node modules, prior to zipping up the /published/ folder which you will re-use for releases into various environments.

During release, i guess we could rerun "npm install --prod" and get it fresh... but it creates 2 problems. 1) You may end up changing the "Build" if npm pkg versions were updated in between release stages. There could be days or weeks between Qa and PRD. 2) npm install takes forever and just makes the build/release process longer. So why bother -- just use the ones with dev-dependencies and it'll go faster.

I guess my issue overall is more closely related to VSTS and npm, as you've said. You can close the issue if you'd like.

[cbadke]

I've run into the same issue and after some screwing around I discovered that running npm install before calling publish results in the node_modules making it into the publish package. I haven't tracked down the root cause but for now it seems that relying on npm install from the prepublish step is not reliable for this purpose.

For now i'll be switching my build to something like

dotnet restore
npm install
dotnet publish -c release

[cbadke]

Upon further investigation, it seems like the publish command takes some sort of inventory and if a folder is missing that is marked in the includes list then that folder is not packaged even if it shows up during prePublish steps. This can be shown by the following (assuming you have npm install as as prePublish)

dotnet restore
mkdir node_modules
dotnet publish -c release

Simple (but dumb?) solution could be to track node_modules as an empty directory in source control so that the folder exists after a fresh clone.

[SteveSandersonMS]

@cbadke Thanks for the info about this. It looks like dotnet publish failing to include dirs that were empty at the start of publishing has been a longstanding and widely reported issue in .NET generally (e.g., https://github.com/dotnet/cli/issues/1396#issuecomment-235767226), and is not going to be fixed until the whole new MSBuild is rolled out.

As per your suggestion, I've amended the templates so they now have a file node_modules/_placeholder.txt which is explicitly included in the .gitignore file. Hopefully this will be enough until the underlying publishing issue is fixed!