Fix source build when using --no-build-js

[MackinnonBuck]

• Checks in blazor.webview.js
• Updates Microsoft.AspNetCore.App.Internal.Assets to build successfully when using --no-build-js, even when the framework JS assets are not on disk

Fixes #59114

[javiercn]

We only need --no-build-nodejs for source build, isn't that the case?

Can we not instead update the check so that in that situation just disable the check that triggers the error when we are running inside source build?

Source build doesn't run any code, it just builds it, and the JS assets are not needed for the build step.

[MackinnonBuck]

We only need --no-build-nodejs for source build, isn't that the case?

Can we not instead update the check so that in that situation just disable the check that triggers the error when we are running inside source build?

Source build doesn't run any code, it just builds it, and the JS assets are not needed for the build step.

Yeah, that sounds good. I'll update this PR to disable the check if not building with NodeJS.

Eventually I think we'll want to change blazor.webview.js to also not be an embedded resource and instead be included as part of M.A.A.Internal.Assets

[javiercn]

@MackinnonBuck do you think instead we could do something like #59135 to avoid checking-in the webview.js file?

[wtgodbe]

We only need --no-build-nodejs for source build, isn't that the case?

I disagree, it's also useful for local builds. By default, if node isn't installed, the build will function as if --no-build-nodejs was passed - that scenario should still work outside of source build.

[MackinnonBuck]

We only need --no-build-nodejs for source build, isn't that the case?

I disagree, it's also useful for local builds. By default, if node isn't installed, the build will function as if --no-build-nodejs was passed - that scenario should still work outside of source build.

If we want this to work more than just the build passing when --no-build-nodejs is specified, my guess is we'd want to do the following:

• For blazor.{web|server|webassembly}.js, fall back on the implicit package reference to Microsoft.AspNetCore.Internal.Assets brought in by the SDK. Note that when building the aspnetcore repo locally, the assets brought in by that package reference do have potential to be out of sync with those that would be produced from a local build.
• For blazor.webview.js, we'd need to either continue checking in the built assets or take a similar approach to the other blazor.*.js assets.

[javiercn]

We only need --no-build-nodejs for source build, isn't that the case?

I disagree, it's also useful for local builds. By default, if node isn't installed, the build will function as if --no-build-nodejs was passed - that scenario should still work outside of source build.

We can make the build not fail, but if you don't have nodejs installed it's impossible to produce a correct set of outputs if they aren't somehow pre-generated. The only reason why that worked in the past is because the JS files were checked-in, which we aren't going to go back to.

We can choose to skip building the webview project if that's what we have to do here.

[ViktorHofer]

We can make the build not fail, but if you don't have nodejs installed it's impossible to produce a correct set of outputs if they aren't somehow pre-generated. The only reason why that worked in the past is because the JS files were checked-in, which we aren't going to go back to.

If it's possible to avoid the node dependency in the product build, that would definitely be preferred from a product construction POV. AspNetCore is the only repository that needs the node dependency when building the .NET SDK product.

[javiercn]

If it's possible to avoid the node dependency in the product build, that would definitely be preferred from a product construction POV. AspNetCore is the only repository that needs the node dependency when building the .NET SDK product.

With the changes that we recently made, nodejs is not required anymore to build the SDK. The Microsoft.AspNetCore.Components.WebView library is a NuGet package, same as the JS assets that will now be downloaded by the app at project build time. I'm fine if we make the repo skip building those two packages when node is not available or explicitly as part of source build.

However, I want to be very clear that our E2E require JavaScript and that there's no way the product can be successfully built without it. This is the exact same situation as it is for wasm, that ships dotnet.js in a similar way.

The only reason this worked in the past was because we manually checked-in the JS asset outputs from the compilation on every release, which is something we are explicitly trying to avoid as it has security implications and causes immense problems for any dev working on the codebase.

[ViktorHofer]

However, I want to be very clear that our E2E require JavaScript and that there's no way the product can be successfully built without it. This is the exact same situation as it is for wasm, that ships dotnet.js in a similar way.

Repo boundaries don't matter when we think about the VMR which builds aspnetcore as one of 30 different repositories. If one repository needs node to build all the expected outputs (including OOB nuget packages) then it's a required dependency. Sounds like node continues to be a design time component in the aspnetcore repo and therefore we need to provide it.

[akoeplinger]

This is the exact same situation as it is for wasm, that ships dotnet.js in a similar way.

One thing that's different for wasm in dotnet/runtime is that we use our own NodeJS build as a nuget package, this works because we can depend on that for the Microsoft build and wasm isn't built in sourcebuild.

[javiercn]

@akoeplinger the parts that we are discussing here aren't either.

They used to be, and that's the bit that we are changing. The discussion is about avoiding a build failure in this case even when no NodeJS version is installed on the machine.

We could certainly switch to bringing in a nodejs version here too, but I don't think we need it.

[javiercn]

@MackinnonBuck I discussed this with @akoeplinger offline.

We will still need nodejs on the VMR to build the product (not just Blazor), so I don't think we need to do any further changes other than avoid breaking during source build.

[MackinnonBuck]

I'm also adding a step in the local validation check to ensure that the build succeeds with -NoBuildNodeJS