Versioning

For NX <= 19, use @nxazure/func version 1.2.0 and lower For NX >= 20, use @nxazure/func version 1.2.1 and higher

Table of Contents

1. Quick Start
2. Features
3. Migrating to v2
4. Known possible issues
5. Publish to Azure
6. Limitations

Quick Start

1. Make sure your environment is set as described in the Azure Functions docs.
2. Make sure you install the latest Azure Functions Core Tools. The minimum required version is 4.0.5390. You can check your currently installed version by running func --version command.
3. Create an NX workspace with any method.

npx create-nx-workspace@latest my-org

3. Add the @nxazure/func package

npm install -D @nxazure/func

4. Initialize a function app

nx g @nxazure/func:init my-new-app --directory=apps/my-new-app

5. Add a function to the app

nx g @nxazure/func:new myNewFunc --project=my-new-app --template="HTTP trigger"

6. Run the function app

nx start my-new-app

Features

1. Support for TS Config paths (e.g., import { tool } from '@my-org/my-lib')
2. Support for a single node_modules folder in the root dir (just like in other monorepo solutions)
3. Environment variables are loaded by NX (from .env files) but they can be overwritten by individual local.settings.json files
4. All current templates that are supported by the func CLI tool are supported.
5. Run multiple functions at once nx run-many --target=start --all
6. Publish the function app straight to your Azure account (az login is required)

Assets

The build executor supports the standard Nx-style assets option on the app's build target. If you use this feature, install the optional peer dependency first:

npm install -D @nx/js

Example direct copy:

{
  "targets": {
    "build": {
      "executor": "@nxazure/func:build",
      "options": {
        "assets": ["apps/my-func/README.md"]
      }
    }
  }
}

Example wildcard copy:

{
  "targets": {
    "build": {
      "executor": "@nxazure/func:build",
      "options": {
        "assets": ["apps/my-func/prompts/**/*.md"]
      }
    }
  }
}

Example object-form asset pattern:

{
  "targets": {
    "build": {
      "executor": "@nxazure/func:build",
      "options": {
        "assets": [
          {
            "input": "apps/my-func/static",
            "glob": "**/*.json",
            "output": "static"
          }
        ]
      }
    }
  }
}

Package.json dependency sync

The build executor can persist the same runtime dependency collection that publish uses. By default, build does not mutate the function app's package.json.

Pass --packageJsonDependencySync=update to copy missing runtime dependencies from the workspace root package.json into the function app's package.json after a successful build:

nx build my-func --packageJsonDependencySync=update

Pass --packageJsonDependencySync=install to update the function app's package.json and run the package manager install command in the function app folder:

nx build my-func --packageJsonDependencySync=install

The install mode leaves generated node_modules and lockfiles in place. Publish still uses a temporary dependency sync and cleans up after itself.

Migrating to v2

The recommended way to migrate is to let Nx run the migrations automatically:

nx migrate @nxazure/func@latest
nx migrate --run-migrations

This will apply all the necessary changes to your workspace. If you prefer to migrate manually (or if the automatic migration didn't run), follow the steps below for each function app project in your workspace.

1. Merge tsconfig.build.json into tsconfig.json

The build executor no longer reads tsconfig.build.json. All TypeScript configuration must live in tsconfig.json.

1. Open tsconfig.build.json in your function app.
2. Copy every compilerOptions entry into tsconfig.json. If the same key exists in both files, use the value from tsconfig.build.json (it was what the build was actually using). Skip noEmitOnError, rootDir, and tsBuildInfoFile — the build executor manages those automatically.
3. Copy any top-level fields like include, exclude, or files into tsconfig.json. Again, if a conflict exists, prefer the tsconfig.build.json value.
4. Make sure compilerOptions.outDir is set (e.g., "dist").
5. Delete tsconfig.build.json.

2. Remove _registerPaths.ts and tsconfig-paths

Runtime path registration has been replaced by a compile-time transformer. The plugin now rewrites import paths during the build, so _registerPaths.ts is no longer needed.

1. Delete _registerPaths.ts from your function app root.
2. If your .eslintrc.json references _registerPaths.ts in ignorePatterns, remove that entry.
3. Remove tsconfig-paths from your workspace root package.json dependencies (if present).

3. Clean up the app-level package.json

The publish executor now automatically discovers runtime dependencies from your source code and injects them at publish time. You no longer need to list them in the app's package.json.

1. Open the package.json in your function app.
2. Remove any dependency that is directly imported in your source code (e.g., @azure/functions). The publish executor will handle these automatically.
3. Keep any dependency that is not imported from your code — these are peer or indirect dependencies that you manage yourself.
4. Add "type": "module" to the package.json.

Example

Before:

{
  "name": "my-func-app",
  "dependencies": {
    "@azure/functions": "^4.0.0",
    "some-manual-peer-dep": "^1.0.0"
  }
}

After (assuming @azure/functions is imported in your code and some-manual-peer-dep is not):

{
  "name": "my-func-app",
  "type": "module",
  "dependencies": {
    "some-manual-peer-dep": "^1.0.0"
  }
}

Known possible issues

1. If after creation the build is failing, try updating @types/node and/or typescript versions.
2. To be able to publish a function to your Azure account, an az login is required first.
3. If you are using the flat eslint config, you might want to add the following to the end of your base config export:

  {
    ignores: ['apps/**/dist'],
  }

4. In many cases, running the function locally requires Azurite to be running. A common symptom is a Connection refused (127.0.0.1:10000) error on startup. This is a standard Azure Functions requirement and applies here as well.

Publish to Azure

1. Sign in to Azure

az login

2. Make sure you select the correct subscription

az account set --subscription "<subscription ID or name>"

You can learn more about it on Microsoft Learn.

3. Configure the Azure Function App name once in the function app's project.json:

{
  "targets": {
    "publish": {
      "executor": "@nxazure/func:publish",
      "options": {
        "name": "my-cool-azure-function-name"
      }
    }
  }
}

To give each developer a separate function app, use environment variable templates in the name. Every {VARIABLE_NAME} token is replaced with that environment variable's value before publishing:

{
  "targets": {
    "publish": {
      "executor": "@nxazure/func:publish",
      "options": {
        "name": "my-cool-azure-function-name-{NXAZURE_FUNCTION_APP_ENV}"
      }
    }
  }
}

Nx loads target-specific environment files, so each developer can create an ignored .env.publish.local file in the function app's root:

NXAZURE_FUNCTION_APP_ENV=alex

Publish then uses the configured name:

nx publish <local-app-name>

4. To publish a single app with a different deployed Azure Function App name, use -n to override the configured name or provide one when it is not configured:

nx publish <local-app-name> -n <function-app-on-azure>

5. If several apps are configured with a publish name, publish them in parallel:

nx run-many -t publish

Missing, blank, or unresolved template values fail before the build starts.

Note: In newer versions of Azure Functions Core Tools, the func binary is no longer bundled inside node_modules, so running npx nx publish will not work. Instead, make sure that both NX and Azure Functions Core Tools are installed globally on your local machine, and that they are pre-installed on the image used in your CI/CD pipeline.

6. Wait for the process to finish and the triggers to properly sync

Limitations

Currently, the plugin supports only TypeScript functions.