[Feature request] Support new properties in azure.yaml for Azure Function app deployment

[lilyjma]

Context

Azd does remote build by default when deploying a Node Function app. Azd also runs npm install and build automatically. These two actions lead to failed deployments if the user tries to deploy the app on a Windows machine. The reason is the following. The generated node_modules/ directory from the install and build step gets included as part of the deployment payload. During deployment, remote build (running on Oryx) tries to run the typescript package inside the directory but that package doesn't work for Linux, so the user gets an Oryx error and deployment fails.

Workaround and problems

Node users need include node_modules/ in .funcignore so that it's excluded during project packaging; remote build will generate a new node_modules/. This workaround isn't ideal because users would have to know the internals of Function app deployment to know this.

This workaround also doesn't address a bigger problem, which is other clients like VSCode don't turn on remote build by default, so users wouldn't have to include node_modules/ in .funcignore. This means depending on how they're deploying the function app, they need different .funcignores, making it difficult to switch between clients.

Ask

• Keep the default today, i.e. remote build is on, for backwards compat purposes but support specifying remoteBuild in azure.yaml for turning it off:

  services:
    api:
      project: .
      language: js
      host: function
      remoteBuild: false | true

How this helps customers: Functions Node customers deploying with azd would specify remoteBuild:false in azure.yaml if they've already built the project locally (perhaps for local testing). If they later switch to another client like VSCode, they can keep the same .funcignore for successful deployment.

• Support skipping npm install and run when remote build is on with packageOnly:

  services:
    api:
      project: .
      language: js
      host: function
      packageOnly: true | false

How this helps customers: For customers that just clone the Function sample and immediately deploy, thepackageOnly: true lets remote build in Oryx run npm install/build, ensuring that the right node_modules/ is generated for deployment.

[anthonychu]

Currently, the package step always runs npm install and build. Can it also look at this setting so it skips those steps when remote build is on?

[vhvb1989]

remoteBuild does not currently apply for functionapp because we don't support deploying containers to functionapp (yet)
We shouldn't use docker.remoteBuild for a non-containers flow.

That being said, I think I understand the requirement as if, for your use case, you don't need to build the service locally because you need to deploy the full source-code to functionapp anyway?

[lilyjma]

@vhvb1989 sorry I think the previous example was confusing. The ask is not to support dpeloying containers to functionapp. I updated the example.

I added more context to the ask. Let me know if that clarifies it.

[vhvb1989]

I understand @lilyjma. You are trying to leverage Oryx only and skip the local build.

I recently updated a project using Azure Functions to use the FlexConsumption from App Service. As part of this change, I switch from using Oryx to directly deploy the /dist folder after building locally. Have you considered this option? This made deployment faster for me (as I don't need to wait for the Oryx remote-build).

For azd, you can define a relative path you want to use for deploy, like

  api:
    project: ./api
    language: js
    host: function
    dist: ./dist

the dist: option can point to the folder you want to use to zip-deploy. In my case I was using TS, so I had to run npm run build anyway to produce the JS in the ./dist folder. If you are using JS directly, you can create one script that copies the files you want to deploy to a folder.
For example, I have these postbuild scripts to copy the host.json and create the runtime.

    "postbuild": "npm run copy:runtime && npm run optimize:prod",
    "copy:runtime": "copyfiles host.json dist/ && npm run create:runtime-package",
    "create:runtime-package": "node -e \"const pkg=require('./package.json'); const runtime={name:pkg.name,version:pkg.version,dependencies:pkg.dependencies,main:'src/functions/*.js'}; require('fs').writeFileSync('dist/package.json', JSON.stringify(runtime,null,2))\"",
    "optimize:prod": "find dist -name '*.js' -type f -exec sed -i '/\\/\\*\\*\\*/d; /\\/\\/ .*$/d; s/[ \\t]*$//g' {} +"

[lilyjma]

Thanks @vhvb1989 for the suggestion. I didn't know you can specify what package you want to deploy directly. I think the experience is good for TS, but I worry about the JS/other languages' experience. It sounds like customers have to create a extra script for copying files, and they have to know what files are required and also get the script right for the deployment to succeed. I worry about these extra steps making deployment more difficult than it needs to be.

@anthonychu what do you think?

[vhvb1989]

@lilyjma , totally get it.
Maybe we need to add something in azd to distinguish between pure node apps (JS only) v/s compilable-node apps (TS or frameworks like Vite, Next, etc).

The first assumption in azd for node app was to always find a build script in the package.json - azd always calls npm run build as part of azd package. We later relax this assumption by adding --if-present in the invocation:

azure-dev/cli/azd/pkg/tools/npm/npm.go

Line 83 in d557287

NewRunArgs("npm", "run", scriptName, "--if-present").

This makes azd compatible with any node-app, even if it doesn't need to be built.

I feel sort of idiomatic to register scripts inside package.json when working with node apps. I have seen some backend applications using scripts to create a bundle after building an static frontend in another folder so it is deployed together with the server. So I feel like using the package.json to define all the package/deployment rules might be a good practice.