Migrate to version 4 of the Node.js programming model for Azure Functions

This article discusses the differences between version 3 and version 4 of the Node.js programming model and how to upgrade an existing v3 app. If you want to create a new v4 app instead of upgrading an existing v3 app, see the tutorial for either Visual Studio Code (VS Code) or Azure Functions Core Tools. This article uses "tip" alerts to highlight the most important concrete actions that you should take to upgrade your app.

Version 4 is designed to provide Node.js developers with the following benefits:

  • Provide a familiar and intuitive experience to Node.js developers.
  • Make the file structure flexible with support for full customization.
  • Switch to a code-centric approach for defining function configuration.


  • The Node.js programming model shouldn't be confused with the Azure Functions runtime:
    • Programming model: Defines how you author your code and is specific to JavaScript and TypeScript.
    • Runtime: Defines underlying behavior of Azure Functions and is shared across all languages.
  • The version of the programming model is strictly tied to the version of the @azure/functions npm package. It's versioned independently of the runtime. Both the runtime and the programming model use the number 4 as their latest major version, but that's a coincidence.
  • You can't mix the v3 and v4 programming models in the same function app. As soon as you register one v4 function in your app, any v3 functions registered in function.json files are ignored.


Version 4 of the Node.js programming model requires the following minimum versions:

Include the npm package

In v4, the @azure/functions npm package contains the primary source code that backs the Node.js programming model. In previous versions, that code shipped directly in Azure and the npm package had only the TypeScript types. You now need to include this package for both TypeScript and JavaScript apps. You can include the package for existing v3 apps, but it isn't required.


Make sure the @azure/functions package is listed in the dependencies section (not devDependencies) of your package.json file. You can install v4 by using the following command:

npm install @azure/functions

Set your app entry point

In v4 of the programming model, you can structure your code however you want. The only files that you need at the root of your app are host.json and package.json.

Otherwise, you define the file structure by setting the main field in your package.json file. You can set the main field to a single file or multiple files by using a glob pattern. Common values for the main field might be:

  • TypeScript:
    • dist/src/index.js
    • dist/src/functions/*.js
  • JavaScript:
    • src/index.js
    • src/functions/*.js


Make sure you define a main field in your package.json file.

Switch the order of arguments

The trigger input, instead of the invocation context, is now the first argument to your function handler. The invocation context, now the second argument, is simplified in v4 and isn't as required as the trigger input. You can leave it off if you aren't using it.


Switch the order of your arguments. For example, if you're using an HTTP trigger, switch (context, request) to either (request, context) or just (request) if you aren't using the context.

Define your function in code

You no longer have to create and maintain those separate function.json configuration files. You can now fully define your functions directly in your TypeScript or JavaScript files. In addition, many properties now have defaults so that you don't have to specify them every time.

const { app } = require("@azure/functions");

app.http('helloWorld1', {
  methods: ['GET', 'POST'],
  handler: async (request, context) => {
    context.log('Http function processed request');

    const name = request.query.get('name') 
      || await request.text() 
      || 'world';

    return { body: `Hello, ${name}!` };


Move the configuration from your function.json file to your code. The type of the trigger corresponds to a method on the app object in the new model. For example, if you use an httpTrigger type in function.json, call app.http() in your code to register the function. If you use timerTrigger, call app.timer().

Review your usage of context

In v4, the context object is simplified to reduce duplication and to make writing unit tests easier. For example, we streamlined the primary input and output so that they're accessed only as the argument and return value of your function handler.

You can't access the primary input and output on the context object anymore, but you must still access secondary inputs and outputs on the context object. For more information about secondary inputs and outputs, see the Node.js developer guide.

Get the primary input as an argument

The primary input is also called the trigger and is the only required input or output. You must have one (and only one) trigger.

Version 4 supports only one way of getting the trigger input, as the first argument:

async function helloWorld1(request, context) {
  const onlyOption = request;


Make sure you aren't using context.req or context.bindings to get the input.

Set the primary output as your return value

Version 4 supports only one way of setting the primary output, through the return value:

return { 
  body: `Hello, ${name}!` 


Make sure you always return the output in your function handler, instead of setting it with the context object.

Create a test context

Version 3 doesn't support creating an invocation context outside the Azure Functions runtime, so authoring unit tests can be difficult. Version 4 allows you to create an instance of the invocation context, although the information during tests isn't detailed unless you add it yourself.

const testInvocationContext = new InvocationContext({
  functionName: 'testFunctionName',
  invocationId: 'testInvocationId'

Review your usage of HTTP types

The HTTP request and response types are now a subset of the fetch standard. They're no longer unique to Azure Functions.

The types use the undici package in Node.js. This package follows the fetch standard and is currently being integrated into Node.js core.


  • Body. You can access the body by using a method specific to the type that you want to receive:

      const body = await request.text();
      const body = await request.json();
      const body = await request.formData();
      const body = await request.arrayBuffer();
      const body = await request.blob();
  • Header:

    const header = request.headers.get('content-type');
  • Query parameter:

    const name = request.query.get('name');


  • Status:

    return { status: 200 };
  • Body:

    return { body: "Hello, world!" };
  • Header. You can set the header in two ways, depending on whether you're using the HttpResponse class or the HttpResponseInit interface:

    const response = new HttpResponse();
    response.headers.set('content-type', 'application/json');
    return response;
    return {
      headers: { 'content-type': 'application/json' }


Update any logic by using the HTTP request or response types to match the new methods. If you're using TypeScript, you'll get build errors if you use old methods.


See the Node.js Troubleshoot guide.