Static-web-apps: How to use TypeScript in Blazor WASM

[PehrGit]

I followed this tutorial link to set up Blazor WASM with an Azure Functions API. The tutorial worked, no problem.

However, I ran into an issue when I started to add some TypeScript. To be able to use Dotnet interop I needed an NPM package "@types/blazor__javascript-interop". No problem, I thought, I'll just add a package.json to install the package and a webpack.config.js to bundle my TS and it's dependencies into an app.js, which I'll put in Client/wwwroot/scripts/app.js.

This works fine locally but the Oryx system now tries to build the client app using NPM instead of dotnet. I found this issue https://github.com/Azure/static-web-apps/issues/173 but that was closed without a resolution other than "delete the package.json" which isn't an option in my case.

Any guidance how I can get this working?

[PehrGit]

Managed to get it working!

In case anyone runs into the same issue, for now this works:

      - name: Build And Deploy
        id: builddeploy
        uses: Azure/[email protected]
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_XXXXXXXX }}
          repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
          action: "upload"
          ###### Repository/Build Configurations - These values can be configured to match you app requirements. ######
          # For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
          app_location: "Client" # App source code path
          api_location: "Api" # Api source code path - optional
          output_location: "wwwroot" # Built app content directory - optional
          app_build_command: "npm run pack && dotnet publish -c Release -o /bin/staticsites/ss-oryx/app/"
          ###### End of Repository/Build Configurations ######

It does feel a little unstable to use the /bin/staticsites/ss-oryx/app/ path directly but for now, it will do.

[anthonychu]

Yeah that path is probably not something you want to depend on. @arroyc @miwebst any thoughts here?

[anthonychu]

@aaronpowell Do you know of another way to solve this?

[aaronpowell]

Having both a package.json and .csproj file in the app_location will cause a challenge with Oryx, as it has to try and work out which one to use and I believe that the package.json will take priority, which is why it's seen as a JavaScript project, not a .NET one. For that specific sort of scenario I'd suggest raising it on the Oryx issues.

I do agree with you @PehrGit that using the internal build path could be unstable, that path could change without notice and you'd have a problem.

Instead, my approach would be to do the npm run pack step as an Action prior to the Build and Deploy step is run, and then "pretend" that it's just a plain Blazor WASM app with some JavaScript files (which were pre-compiled before the SWA step runs). I've done that myself when I've got more complex build pipelines than Oryx can support (see https://github.com/aaronpowell/react-static-web-apps-auth/blob/main/.github/workflows/azure-static-web-apps-witty-water-0d73b881e.yml).

This way the responsibility of Oryx is not to build and publish everything, it's only to build and publish the core app.

[PehrGit]

Thanks for the suggestions. I ended up using a combination of https://github.com/aaronpowell/react-static-web-apps-auth/blob/main/.github/workflows/azure-static-web-apps-witty-water-0d73b881e.yml and https://github.com/mschleifer/FantasyLeagueReport/commit/2727b1cf5919df1f8b148fcab8ff0e439d05a021#diff-72b4c71fe3ac161941abd3de5179e119f859f11e7d8b2fd094985fe27866d9a8 which I found via https://github.com/microsoft/Oryx/issues/879.

Basically I bypass Oryx completely for the client project. Fortunately Oryx recognises the build has already been done and just handles the upload, which is a nice surprise. For now I'm fine with using this workaround, I'll revisit this when we get to Azure/[email protected] :)
Final yaml:

  build_and_deploy_job:
    if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
    runs-on: ubuntu-latest
    name: Build and Deploy Job
    steps:
      - uses: actions/checkout@v2
        with:
          submodules: true
      - run: |
          npm install
          npm run build:azure
        name: Webpack client
        working-directory: Client        
      - name: Download .NET 5
        uses: actions/setup-dotnet@v1
        with:
          dotnet-version: '5.0.x'
      - name: .NET publish client
        run: dotnet publish ./Client/Client.csproj -c Release -o blazor -f NET5.0
      - name: Build And Deploy
        id: builddeploy
        uses: Azure/[email protected]
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_xxx }}
          repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
          action: "upload"
          ###### Repository/Build Configurations - These values can be configured to match you app requirements. ######
          # For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
          app_location: "blazor/wwwroot" # App source code path
          api_location: "Api" # Api source code path - optional
          output_location: "blazor" # Built app content directory - optional
          ###### End of Repository/Build Configurations ######

[aaronpowell]

Yeah, the upload will be fine if you have all the assets pre-compiled, as the build tool just goes "huh, nothing to build, I'll upload assets", which is also useful if you're doing a site with no pre-processing at all (like, a vanilla HTML site, madness! 😂).

[arroyc]

@anthonychu thanks for summoning me here .. I will take a look at it now ..

I have some proposals and will discuss this with @miwebst and update this thread here

[anthonychu]

@arroyc @miwebst were you able to find a solution to this?

[anthonychu]

Looking into this further, it doesn't seem like a very common scenario and using separate, custom build steps will likely provide the best results here. There are quite a few assumptions and changes we need to make to Oryx to support this.

@aaronpowell @PehrGit Let us know if you think there's value in providing more built-in support for this scenario.

[PehrGit]

Looking into this further, it doesn't seem like a very common scenario and using separate, custom build steps will likely provide the best results here. There are quite a few assumptions and changes we need to make to Oryx to support this.

@aaronpowell @PehrGit Let us know if you think there's value in providing more built-in support for this scenario.

Thanks for looking into it @anthonychu. I would expect this to be a very common scenario. I would think that as Blazor WASM is targeted towards C# developers that many of its users would prefer to use TypeScript over vanilla Javascript. I base that on the assumption that, like me, the average C# developer is more comfortable with TS than JS.

[erikporter]

@PehrGit Thanks so much for the above solution. Had to modify it a bit, but this worked great for my scenario too (Deploy Blazor WebAssembly from Azure DevOps, but need a specific build/publish configuration)!

To tack onto what @PehrGit said, I think an even more generic scenario will be needed by people here, which is wanting to not use Oryx to do the build/publish for C# because you need to do some other things in your build (in my case, custom configuration that did some extra build work). Would be great to have some documentation or some more parameters on the Static Web App task that let you do it as part of the Oryx build or something similar.

This is where I landed if it's helpful to anyone...

  - task: DotNetCoreCLI@2
    displayName: Publish $(MyCustomBuildConfiguration) Website
    inputs:
      command: 'publish'
      publishWebProjects: false
      projects: 'MyBlazorApp/MyBlazorApp.csproj'
      arguments: '--configuration $(MyCustomBuildConfiguration) --output blazor'
      zipAfterPublish: false
      modifyOutputPath: false
  - task: AzureStaticWebApp@0
    inputs:
      app_location: 'blazor/wwwroot'
      output_location: 'wwwroot'
    env:
      azure_static_web_apps_api_token: $(MyStaticStaticWebApp-DeploymentToken)