[CheckJs Error]: Cannot find name 'Buffer'

[oscard0m]

Cannot find name 'Buffer'. Do you need to install type definitions for node? Try npm i --save-dev @types/node.

---

I'm not familiar with working with JavaScript with checkJs, do you think we should install @types/node as VS Code suggests?

[gr2m]

I've used Buffer directly in a few scripts because I needed base64 en/decoding due to GitHub's contents APIs:

• https://docs.github.com/en/rest/reference/repos#get-repository-content
• https://docs.github.com/en/rest/reference/repos#create-or-update-file-contents

In browsers / Deno, we can use atob/btoa. In Node, we can polyfill the methods like this:

https://github.com/gr2m/octoherd-script-normalize-package-repository-field/blob/0272b1555ba5479e01e7a240d3e5ec646024bf37/script.js#L85-L92

I think I'll probably add a method directly to @octoherd/octokit for file updates. But for the time being, we can polyfill.

Regarding the error

Cannot find name 'Buffer'

I'd just disable the error for now.

[oscard0m]

Created a follow up issues for:

• @octoherd/octokit method: Implement method for file updates using base64 en/decoding (due to GitHub's contents APIs) octokit#8
• Usage of atob/btoa + Polyfill for Node: Use atob/btoa instead of Buffer for Base64 en/decode #11
• Discussion to start covering Deno and Browser in CI checks for scripts: CI checks scripts work in Browsers and Deno (not only Node) octoherd#13

[oscard0m]

Cannot find name 'Buffer'

I'd just disable the error for now.

Already disabled by #9

I posted an issue in StackOverflow (did not find any issue regarding this in TypeScript's GitHub in a quick search) to see if it's possible to @ts-expect-error for some kind of errors only: https://stackoverflow.com/questions/66522131/ts-expect-error-only-for-a-certain-type-of-error

Texted @G-Rath because I saw him using it here for example: https://github.com/octokit/webhooks.js/blame/aad9b74ba90f8ca633c811231f1f566f59e241bd/test/typescript-validate.ts#L19

[G-Rath]

Texted @G-Rath because I saw him using it here for example:

I formatted it like that as capturing the expected comment, but it doesn't actually interact with // @ts-expect-error at all. Feel free to adjust those comments to make that clearer if you'd like.

---

You should be able to resolve this without @types/node with this:

declare global {
  interface Buffer {}
}

I'm not familiar with working with JavaScript with checkJs, do you think we should install @types/node as VS Code suggests?

Yes, I would recommend that - that suggestion actually comes from TypeScript; the only reason not to do it is if you're not in a node env and so can't use node globals such as process, console etc.

Even then those globals are usually always polyfilable, so it's typically fine to use @types/node regardless.

(Aside from the globals, you can avoid everything else brought in by @types/node by just not importing the native modules - since that's all it adds).

[oscard0m]

@G-Rath thanks for the detailed explanation. As always, is a pleasure reading you.

Feel free to adjust those comments to make that clearer if you'd like.

It's fine, I just wanted to know if it works but was not working to me or was just info added to the comment

---

Seems like @gr2m wants to give support to other environments as Browser and Deno so... maybe it's ok to not use @types/node and point to a cross-platform solution? What's your opinion on that @G-Rath

[gr2m]

the only reason not to do it is if you're not in a node env

that's exactly the reason why I would not add it. @octoherd scripts should run universally in Node 12+/Deno/evergreen Browsers

[G-Rath]

Even then those globals are usually always polyfilable, so it's typically fine to use @types/node regardless.

But if you really don't want to use @types/node (which is fine), the declare global method is the way to go :)

[gr2m]

I wouldn't, because if we just use Buffer without any precaution, then the script will only work in Node. Getting the error from the type check is a feature, not a bug, in my opinion. I think we should properly check that Buffer exists before using it, instead of just assuming that it does.

In this particular case I will encapsulate the base64 encoding into a plugin, so this will be a non-problem for scripts after that.