ClientApp/dist and wwwroot/dist files missing after cloning with git

[starquake]

Running project fails because of missing files in ClientApp/dist/* and wwwroot/dist/*

Cannot find module './wwwroot/dist/vendor-manifest.json'
Steps to reproduce:

• Create a project with dotnet new angular
• Push it to a git repository
• Clone the project somewhere else
• run dotnet restore
• run npm install
• run application in development mode, either with visual studio code or VS2017

It can be fixed by doing dotnet publish, but that shouldn't be required, right? And how would I do that in vs2017?

Or am I doing something wrong?

[KraigWalker]

You need to run: webpack --config webpack.config.vendor.js first to build you shared libraries DLL bundle, which is built desperately as it usually never changes.

…

Sent from my iPhone

On 21 Mar 2017, at 17:06, Jan Visser ***@***.***> wrote: Running project fails because of missing files in ClientApp/dist/* and wwwroot/dist/* Cannot find module './wwwroot/dist/vendor-manifest.json' Steps to reproduce: Create a project with dotnet new angular Push it to a git repository Clone the project somewhere else run dotnet restore run npm install run application in development mode, either with visual studio code or VS2017 It can be fixed by doing dotnet publish, but that shouldn't be required, right? And how would I do that in vs2017? Or am I doing something wrong? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[starquake]

I know how to fix it.

But this was the important part of my question:

It can be fixed by doing dotnet publish, but that shouldn't be required, right? And how would I do that in vs2017?

To put in another way: Visual Studio automatically runs dotnet restore and npm install. It doesn't run webpack however. Should I add this to a README.md to inform developers to run these comments? Or should I add this in a build step to make sure dotnet build runs webpack? Or maybe on project open or something?

And what I ultimately mean: Shouldn't this scenario be covered by the template?

[SteveSandersonMS]

Running webpack is an aspect of building your application, just like compiling the .NET code is also needed before it runs. The options are:

• We could make it run webpack automatically when you build your .NET code. However, that would slow down every .NET build, even when you don't need to re-run webpack.
• We could make it run webpack automatically when you start up your app. However, rebuilding vendor files can be slow, so this slows down every app startup.
• You could add the wwwroot/dist/* and ClientApp/dist/* files to your source control repo, so they are restored as part of the git clone. That works fine, but you will then be committing diffs to those files on basically every change. It's equivalent to including your .NET bin and obj folders in source control.

The most standard solution we have at the moment is to say that webpack is a build process, so developers should expect to run it before the app can run. I know there's some inconvenience with this, but I'm not aware of an all-round better solution right now :)

[starquake]

Thanks for this amazingly complete answer!

[peter-bozovic]

Here is the solution I have ended up with.

Add within package.json, under "scripts" part:
"postinstall": "webpack --config webpack.config.vendor.js"

This will make vendor pack rebuild whenever the npm install is run, so whenever you change anything in your packages configuration or when you open VS for the first time and everything is loaded up by package manager.

[QuantumHive]

@SteveSandersonMS

The most standard solution we have at the moment is to say that webpack is a build process, so developers should expect to run it before the app can run.

Perhaps explicitly mention in the docs how to use the build process? For example, explicitly mention that developers need to install webpack globally with npm:

npm install -g webpack

For those that are new, they might not understand the build process in the front-end web dev world ;)
I know from the point of view of JavaScriptServices this is an obvious process, but it's not that obvious for newbies.

[spottedmahn]

The latest sources contain a bit of extra logic in the csproj to run webpack if you don't have the dist folder on disk - issue 477

[simeyla]

For me the issue was that I didn't have the targets in the csproj file to actually build the dist folder - so it was publishing an incomplete build.

  <PropertyGroup>
    <SpaRoot>ClientApp\</SpaRoot>
    ...

  <Target Name="PublishRunWebpack" AfterTargets="ComputeFilesToPublish">
    <!-- As part of publishing, ensure the JS resources are freshly built in production mode -->
    <Exec WorkingDirectory="$(SpaRoot)" Command="npm install" />
    <Exec WorkingDirectory="$(SpaRoot)" Command="npm run build -- --prod" />
    <Exec WorkingDirectory="$(SpaRoot)" Command="npm run build:ssr -- --prod" Condition=" '$(BuildServerSideRenderer)' == 'true' " />
  ....

(deliberately incomplete...)

A definite pitfall of csproj vs. project.json is that it's very easy to forget there is logic in csproj, and i also doesn't show up when you do CTRL-F. So it took me a while to realize this.

Also you can run dotnet publish in a package manager console to verify it works ok. You don't need to do it through the Publish menu item. This way probably exposes errors better than running Publish. Look in bin/debug/publish/ClientApp/ and make sure you have dist` folder.