fix(nuxt): add @types/node as a peerDependency

[danielroe]

🔗 Linked issue

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

This aims to improve DX by installing @types/node by default (but respecting user's preference if they install a different version, to match their own node version).

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[codesandbox]

  Open in CodeSandbox Web Editor | VS Code | VS Code Insiders

[nuxt-studio-dev]

✅ Live Preview ready!

Name	Edit	Preview	Latest Commit
Nuxt Docs	Edit on Studio ↗︎	View Live Preview	4395922

[nuxt-studio]

✅ Live Preview ready!

Name	Edit	Preview	Latest Commit
Nuxt Docs	Edit on Studio ↗︎	View Live Preview	a43c4eb

[antfu]

Makes sense to me 👍

[pi0]

Can't we do this simply by adding typescript and @types/node to default starter templates as devDependendencies? (I often found typescript is missing and IDE not detecting features properly until installing it)

Peer dependency behavior of package managers is sometimes annoying we never added them to nuxt package for this reason.

[danielroe]

Could we do both (add as peerDep and also in starter)? @types/node is really required for the types to work (e.g. process.dev), but we ideally want to defer to the user to pick which version (16/18/etc.). Even if package manager force installs @types/node, I don't see an issue with it.

[pi0]

Isn’t it enough to add dev dependencies to starter templates to fix the issues?

[danielroe]

I think it would fix the issue for new projects, but not affect existing ones.

What are you worried that this change might do?

[pi0]

We could simply instruct old projects to install both typescript and @types/node packages as currently documented if this change is purely for them.

I am even up to supporting nuxi typescript setup command to automate local ts setup :)

Package managers never had a persistent and predictable behavior with peer dependency handling. We might need to always keep updating a new range for supported node and for (even small!) fragment of users are not using typescript, it is just an additional dependency forced to install (or see warn)

[danielroe]

You're right, we would need to keep updating the range. But we currently need to do the exact same thing for engines.node, which is a couple of lines further down the file. I think keeping them in sync isn't too much.

Of course we can tell people to add the dependency themselves (and we should). But I think this is exactly the purpose for which we have peerDeps, right?

I'm still not sure what disadvantages there would be to this. I'm not suggesting adding typescript which would definitely be too much for those not using type-checking. But @types/node is used and picked up by IDEs even if users don't use type-checking, and will result in a broken experience if missing. See, for example #20040 (comment).

I am very happy to revert this change (or enable peerDependenciesMeta.optional, as vite does) if we experience any negative issues.

[pi0]

TBH I'm still not 100% convinced this is the best way to solve the issue with peerDependencies while simply should be solved in starter (and anyway we need to add devDependency there too) but let's try doing it...

[kpetrillo]

I'm still receiving this error after upgrading to v3.4.0. I've also installed @types/node manually as well.

[danielroe]

@kpetrillo I'm not sure what issue you're referring to. Would you create a new issue - with a reproduction?