As of 6 hours ago (when DefinitelyTyped/DefinitelyTyped#72589 was merged) the latest Node types conflict with the types for this library so lots of downstream builds will start failing. If you try to use both, you get:
Error: node_modules/@types/node/url.d.ts(997,19): error TS2300: Duplicate identifier 'URLPatternInit'.
Error: node_modules/@types/node/url.d.ts(998,19): error TS2300: Duplicate identifier 'URLPatternResult'.
Error: node_modules/@types/node/url.d.ts(999,19): error TS2300: Duplicate identifier 'URLPattern'.
Error: node_modules/@types/node/url.d.ts(1000,13): error TS2300: Duplicate identifier 'URLPattern'.
Error: node_modules/urlpattern-polyfill/dist/index.d.ts(5,9): error TS2300: Duplicate identifier 'URLPattern'.
Error: node_modules/urlpattern-polyfill/dist/index.d.ts(6,8): error TS2300: Duplicate identifier 'URLPatternInit'.
Error: node_modules/urlpattern-polyfill/dist/index.d.ts(7,8): error TS2300: Duplicate identifier 'URLPatternResult'.
This is eventually going to break every TypeScript project using this module with Node.js.
Eventually microsoft/TypeScript-DOM-lib-generator#1199 will get resolved, and the same conflict will probably also apply to anybody using TypeScript's DOM types and this library.
This happens because both Node's types & this library's types declare the same conflicting global. Even if you use the library only as a ponyfill or only on-demand (so the runtime globals don't actually ever conflict), you'll still run into this problem at the type level unfortunately.
In some cases downstream projects can pin to an older version of Node types, but if you have use this library within another library that intends to support modern Node versions, that's not very practical (every library down to the end user application would also have to pin the same Node types version or deal with conflicts).
One possible solution is to have two entrypoints:
- One global entrypoint, e.g.
import "urlpattern-polyfill/global" which sets the global, where urlpattern-polyfill/global.d.ts adds these types to globalThis.
- One non-global entrypoint, e.g.
import "urlpattern-polyfill/ponyfill" which doesn't expose the library globally, and just allows manual importing without modifying any globals. urlpattern-polyfill/ponyfill.d.ts would then just export the actual type for importing, without modifying globalThis.
Entrypoint naming is open for debate, either one could be the default provided by a bare import "urlpattern-polyfill". This would be a non-breaking change if you just add a new entrypoint without changing the current import behaviour, or you might want to make the non-global option the default (a breaking change) if you want to ensure this works out of the box in future.
As of 6 hours ago (when DefinitelyTyped/DefinitelyTyped#72589 was merged) the latest Node types conflict with the types for this library so lots of downstream builds will start failing. If you try to use both, you get:
This is eventually going to break every TypeScript project using this module with Node.js.
Eventually microsoft/TypeScript-DOM-lib-generator#1199 will get resolved, and the same conflict will probably also apply to anybody using TypeScript's DOM types and this library.
This happens because both Node's types & this library's types declare the same conflicting global. Even if you use the library only as a ponyfill or only on-demand (so the runtime globals don't actually ever conflict), you'll still run into this problem at the type level unfortunately.
In some cases downstream projects can pin to an older version of Node types, but if you have use this library within another library that intends to support modern Node versions, that's not very practical (every library down to the end user application would also have to pin the same Node types version or deal with conflicts).
One possible solution is to have two entrypoints:
import "urlpattern-polyfill/global"which sets the global, whereurlpattern-polyfill/global.d.tsadds these types toglobalThis.import "urlpattern-polyfill/ponyfill"which doesn't expose the library globally, and just allows manual importing without modifying any globals.urlpattern-polyfill/ponyfill.d.tswould then just export the actual type for importing, without modifyingglobalThis.Entrypoint naming is open for debate, either one could be the default provided by a bare
import "urlpattern-polyfill". This would be a non-breaking change if you just add a new entrypoint without changing the current import behaviour, or you might want to make the non-global option the default (a breaking change) if you want to ensure this works out of the box in future.