An error occurs when debugging a TypeScript project

[v-ruizh]

OS: All
Build Version: 20220526.13

Repro Steps:

1. Create a TypeScript project with HttpTrigger function.
2. Debug it.
3. Check whether succeeds to debug the project or not.

Expect:
Succeed to debug a TypeScript project.

Actual:
An error occurs when debugging a TypeScript project.

More Info:
This issue does not reproduce after executing command "npm i --save-dev @types/node".

[alexweininger]

This reproduces on v1.7.1 also. Seems like a templates issue

[ejizba]

This was due to a recent release of the "@azure/functions" types package which references "Buffer" for the first time. Filed this issue to investigate if we can fix on the types side, but I'm not optimistic: Azure/azure-functions-nodejs-worker#587

The "template" for TypeScript projects is owned by the VS Code extension, so it might be on the extension to address. We went back and forth on whether "@types/node" should be included in TypeScript projects by default in the past (for example here), but that was when @azure/functions didn't reference any node types. The main problem is knowing which version to pick.

[alexweininger]

A postinstall script could check the installed node version and install the corresponding @types/node package.

[ejizba]

Do you have examples of other types packages doing that? I don't really want to re-invent the wheel here as I think it's a very common thing for types packages to reference node types. I'd rather just follow what other popular packages are doing

[alexweininger]

Do you have examples of other types packages doing that?

Yeah I don't have any examples. 😄

I just tested out enabling the skipLibCheck option in the tsconfig.json and it makes the error go away. Maybe the template could enable that by default?

I know that's not optimal, but TypeScript is exploring better options for skipLibCheck.

[ejizba]

@alexweininger Would you be fine if we add @types/node to the default template in VS Code? I think that's the most common solution. For example if I do yo code for a new VS Code extension it'll have @types/node set to 16.x. It's a bit more complicated for Functions because of the version matrix, but I'd probably do some mix of trying to match the user's local version and using known versions that are supported for Functions.

If you're fine with the change, I'm happy to submit a PR myself. I will have to make the same change in core tools as well

[bwateratmsft]

I think it would be sensible to do that, with either v16 (active LTS) or v14 (maintenance LTS). Everything below 14 is out-of-support, so I don't feel bad if we scaffold e.g. v14 and a user on v12 has issues. They should not be on v12.

[alexweininger]

Sounds good to me 👍

[v-ruizh]

Verified this issue on the extension build 20220606.8, it has been fixed.

[alexweininger]

Thank you @v-ruizh!