"@azure/functions-core" can't be resolved by bundlers

[pcj]

When using a bundler such as esbuild, bundling @azure/functions causes this error:

✘ [ERROR] Could not resolve "@azure/functions-core"

    node_modules/@azure/functions/dist/azure-functions.js:1657:25:
      1657 │ module.exports = require("@azure/functions-core");

NOTE: bundling with ncc has same problem but esbuild emits a better error message

There is no published npm module @azure/functions-core.

I see that there is a path mapping in tsconfig.json, perhaps it's a shim for old or MS internal code?

In any case, this breaks bundlers and is very annoying. Can we please get this removed from the tsconfig and just use the correct internal import reference?

[pcj]

{
  "scripts": {
      "compile": "tsc",
      "bundle": "esbuild dist/src/azure/main.js --bundle --platform=node --external:@azure/functions-core --outfile=dist/index.js",
  },
  "main": "dist/index.js"
}

This is what I'm using, hope it's correct.

[ejizba]

Hi @pcj, "@azure/functions-core" is a built-in module that ships directly in Azure, not through npm. I understand this breaks bundlers, but it's an important piece that links your app code to the underlying Azure Functions runtime. It's analogous to how "path" is a built-in module that ships directly in Node.js. In both cases, the Azure Functions runtime and the Node.js runtime are providing functionality unique to their environment through these modules.

Most of our customers actually don't need to bundle their app. We highly recommend you run from a package file, which provides the performance benefits of bundling and is a lot easier to configure.

If you still need to use a bundler, then yes the recommendation is to list "@azure/functions-core" as an external package so that your bundler will ignore it.

[pcj]

@ejizba Thank you for a prompt response.

Personally I think "running from a package file" is somewhat orthogonal to this issue, because the customer is still responsible for creating the zip file, which in the naive case just zipping up everything including the node_modules/ directory.

In my case, that would be difference of having a deployment zip file around 725M rather than 5M. So, deployments would be much slower.

Maybe I missed something about kudu or some other thing regarding zip deployments, because from where I am standing there is no built-in performance benefit.

I personally do recommend a bundler for this reason.

But I'll go ahead and close the issue. Hopefully it helps someone else in the future.

[pcj]

Also, your comment:

"@azure/functions-core" is a built-in module that ships directly in Azure, not through npm.

Is very helpful, I didn't find this documented elsewhere.

[ejizba]

You're correct it would not help with deployment performance at all. I was talking about performance of running your app, specifically every time an instance is started which loads your app code. Instances can be recycled often so the startup performance is definitely important.

Another option for speeding up deployments is to run npm prune --production right before you deploy. I find that dev dependencies often account for a large amount of the "node_modules" folder size. But if you already got your bundler working and are happy with that, I see no reason to stop using it.

Is very helpful, I didn't find this documented elsewhere.

This was a relatively recent thing starting with the new programming model that just GA-ed in September. We knew the core module wouldn't work with bundlers, but you're the first person to bring it up. I expect you won't be the last, so I can re-open this issue to track doc improvements.