Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type of global navigator object incorrect since node.js 21 #60387

Closed
fabb opened this issue Nov 1, 2024 · 5 comments
Closed

Type of global navigator object incorrect since node.js 21 #60387

fabb opened this issue Nov 1, 2024 · 5 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@fabb
Copy link

fabb commented Nov 1, 2024

πŸ”Ž Search Terms

navigator, node

πŸ•— Version & Regression Information

  • This issue happens since updating to node.js 21

⏯ Playground Link

No response

πŸ’» Code

This is a next.js app with server-rendering.

export const EditorControls: FunctionComponent<EditorControlsProps> = (props) => {
    const metaKey = typeof navigator !== 'undefined' && navigator.appVersion.indexOf('Mac') !== -1 ? '⌘' : 'Strg'
    return null
}

πŸ™ Actual behavior

This crashes at runtime because since node.js 21, a global navigator object was introduced which only contains a few keys and is not compatible with the Navigator interface defined in lib.dom.d.ts. See nodejs/node#50269

πŸ™‚ Expected behavior

Typescript should regard the node.js navigator object type and make all keys on it optional, except when accessed via window.navigator

Additional information about the issue

No response

@MartinJohns
Copy link
Contributor

Typescript should regard the node.js navigator object type and make all keys on it optional

That would be a massive breaking change for something that's essentially a configuration error. You shouldn't be using lib.dom.d.ts in a NodeJS context. And there's a lot more in this definition file that's not supported by NodeJS, you want to make that all optional too, or special case this one instance?

@fabb
Copy link
Author

fabb commented Nov 1, 2024

If itβ€˜s a configuration error, then it affects all react frameworks I know. React projects that do server rendering execute the same code on server and client, so we have to include lib.dom. Open for suggestions.

@Josh-Cena
Copy link
Contributor

That would be an issue far more general than this: #53971

@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Nov 8, 2024
@RyanCavanaugh
Copy link
Member

The reality is that many projects end up with both node and DOM typings loaded at the same time due to transitive dependencies. There's not really a straightforward solution that would fix this situation without breaking huge swathes of working code.

@typescript-bot
Copy link
Collaborator

This issue has been marked as "Working as Intended" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

@typescript-bot typescript-bot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

5 participants