`@react-aria/utils` comes with TypeScript error after upgrading to `3.29.0`

[SimenB]

Provide a general summary of the issue here

Node is imported: https://www.runpkg.com/?@react-aria/utils@3.29.0/dist/types.d.ts#2 for use in https://www.runpkg.com/?@react-aria/utils@3.29.0/dist/types.d.ts#255

But the rest of the file uses the global DOM Node: https://developer.mozilla.org/en-US/docs/Web/API/Node

And thus there are 15 type errors with Generic type 'Node<T>' requires 1 type argument(s)

🤔 Expected Behavior?

No type errors

😯 Current Behavior

15 type errors

💁 Possible Solution

We're using this patch with yarn:

diff --git a/dist/types.d.ts b/dist/types.d.ts
index 450eeadf47a71c6d5876cf8e4e4f77e82b74a4a6..e0e72eba486f9014807cb3c501ba99a85509ec84 100644
--- a/dist/types.d.ts
+++ b/dist/types.d.ts
@@ -1,5 +1,5 @@
 import React, { MutableRefObject, Ref, DOMAttributes, JSX, ReactNode, HTMLAttributes, EffectCallback, Dispatch, RefObject as _RefObject1 } from "react";
-import { AriaLabelingProps, DOMProps, LinkDOMProps, FocusableElement, Orientation, Href, RouterOptions, RefObject, AsyncLoadable, Collection, Node } from "@react-types/shared";
+import { AriaLabelingProps, DOMProps, LinkDOMProps, FocusableElement, Orientation, Href, RouterOptions, RefObject, AsyncLoadable, Collection, Node as AriaNode} from "@react-types/shared";
 export const useLayoutEffect: typeof React.useLayoutEffect;
 /**
  * If a default is not provided, generate an id.
@@ -252,7 +252,7 @@ interface LoadMoreProps {
 }
 export function useLoadMore(props: LoadMoreProps, ref: _RefObject1<HTMLElement | null>): void;
 export interface LoadMoreSentinelProps extends Omit<AsyncLoadable, 'isLoading'> {
-    collection: Collection<Node<unknown>>;
+    collection: Collection<AriaNode<unknown>>;
     /**
      * The amount of offset from the bottom of your scrollable region that should trigger load more.
      * Uses a percentage value relative to the scroll body's client height. Load more is then triggered

I'm not sure how the d.ts ended up being wrong - would have thought TypeScript handled this correctly? Or maybe there's some types bundling that causes this?

🔦 Context

No response

🖥️ Steps to Reproduce

I don't think this is needed? Happy to provide one if it is, tho

Version

@react-aria/utils@3.29.0

What browsers are you seeing the problem on?

Other

If other, please specify.

TypeScript error

What operating system are you using?

N/A

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

[LFDanLu]

I guess we can add something to alias any Node imports from @react-types in a post build step to make sure this doesn't happen, surprised myself that this hasn't happened before. @snowystinger have you encountered this before? I wasn't able to find anything in our repo where we are handling possible collisions like this where the type in a isolated package file might be fine but collides due to the types file being generated for the package as a whole.

[snowystinger]

Maybe we could do something like https://stackoverflow.com/questions/74810107/handling-local-types-name-collision-with-global-native-types
Then we could have an eslint rule to check that we aren't using the global Node unless we explicitly mean to use it.

I'm also surprised that typescript hasn't handled this correctly, everything looks like it should be above water.

[LFDanLu]

Perhaps a parcel bug since typescript generates individual types files and parcel is then responsible for batching those into the package level types files, will need to investigate.