build: add node v18 support

[Shinigami92]

Description

• Remove support for node v12 and v17 I will split the node v12 support removal into it's own PR (build!: remove node v12 support #7833)
• Add support for node v18

Additional context

• https://nodejs.org/en/about/releases/
• https://twitter.com/BethGriggs_/status/1516449244034519041

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[Shinigami92]

Note for myself: need to update

vite/package.json

Line 40 in 9c6501d

"@types/node": "^16.11.27",

[Shinigami92]

Awaiting v18 types

[Shinigami92]

Work on @types/node has started:

• feat(node): v18 DefinitelyTyped/DefinitelyTyped#60047
• fix(node): in node@18 'AddressInfo.family' is number DefinitelyTyped/DefinitelyTyped#60042

[sodatea]

It's due to this breaking change: nodejs/node#41431

vite/packages/vite/src/node/logger.ts

Line 193 in ba43c29

.filter((detail) => detail && detail.address && detail.family === 'IPv4')

In Node.js < 18, detail.family is a string; in Node.js >= 18, it's an integer.

[Shinigami92]

I'm not 💯 % sure, but maybe the failing node-18-windows job is a jest node-18 globalTeardown bug?

[sodatea]

About the failing test on WIndows:

• I don't see anything wrong with the specific test case except it's the last one that gets executed.
• So I think, even if it's a real issue, it's likely to be a bug with Jest and Node.js 18, we can safely ignore it…
• …until someone with a Windows machine can actually help debug it.

[sodatea]

Done a little research and found a possible culprit: jprichardson/node-fs-extra#646

Now that we also have rimraf in dependencies, maybe we can replace the fs.removeSync in jestGlobalTeardown.cjs with rimraf and see what happens?

Related commits:

• isaacs/rimraf@d53235d
• https://github.com/jprichardson/node-fs-extra/pull/646/files

rimraf retries 100 times; fs-extra retries for 500ms.
So rimraf is likely to fail on very fast machines and fs-extra may fail on slow machines…

[Shinigami92]

Done a little research and found a possible culprit: jprichardson/node-fs-extra#646

Now that we also have rimraf in dependencies, maybe we can replace the fs.removeSync in jestGlobalTeardown.cjs with rimraf and see what happens?

Related commits:

• isaacs/rimraf@d53235d
• jprichardson/node-fs-extra#646 (files)

rimraf retries 100 times; fs-extra retries for 500ms. So rimraf is likely to fail on very fast machines and fs-extra may fail on slow machines…

I may do this this evening or weekend in a separate PR, need to be "afk" for a while
In the meantime, I would suggest that we already merge this PR as it fixes already a compatibility log bug 🙂

[patak-dev]

@Shinigami92 I see that this was marked for 3.0, this is ok to be released in 2.9 though, no?

[Shinigami92]

Yes, I marked it with 3.0 as I also deprecated v12 in one PR
Now I split them into separate 👍