Global export type conflict with Recurly node client

[rishibajekal]

Overview

I have a monolith project that relies on both the Recurly node client as well as React-Recurly.

The Recurly node client exports a global namespace in its types file (node_modules/recurly/lib/recurly.d.ts):

export as namespace recurly;

React Recurly depends on recurly.js types (node_modules/@types/recurly__recurly-js/index.d.ts), which exports a global recurly:

declare global {
  interface Window {
    recurly: Recurly;
  }
  const recurly: Recurly;
}

The issue I'm encountering is that the global defined by the node client is clashing with that of the recurly.js types file.

Error

node_modules/@types/recurly__recurly-js/index.d.ts:14:9 - error TS2403: Subsequent variable declarations must have the same type.  Variable 'recurly' must be of type 'typeof import("node_modules/recurly/lib/recurly")', but here has type 'Recurly'.
14   const recurly: Recurly;
           ~~~~~~~
  node_modules/recurly/lib/recurly.d.ts:5:1
    5 export as namespace recurly;
      ~~~~~~
    'recurly' was also declared here.

TypeScript limitation

There is a known limitation in TypeScript that global type definitions can only be included but not excluded, which makes it quite difficult to get around this issue for projects that encounter it. I have tried within my project to follow the suggested workaround but I'm still unable to avoid the error above.

Questions

1. I imagine using both these packages within the same project is a fairly common scenario. Are there any known workarounds?
2. Can the next version of one or both of the packages rename the global exports to avoid this conflict?

[chrissrogers]

@rishibajekal thanks for the details you've provided here, it's really helpful.

It's actually relatively uncommon to use both packages within the same project, at least in terms of the build/compile.

It may be some time before either this library or recurly-client-node bumps its major version, since we have a general policy to not introduce breaking changes unless absolutely necessary. I suspect moving either out of a conflicting namespace will be something we'd want to do, though.

I would suggest separating the builds for your node environment and front-end if possible. They are separate execution environments and it's a sensible location to draw a line.

[gentle-noah]

+1

[angrycat9000]

Ran into this problem was as well in a monorepo with yarn workspaces. The client and the server packages were used in different workspaces, however because of how yarn workspaces work, all the npm modules were hoisted up to the repo root node_modules. This resulted in server typescript build finding the client typings.

The work around was to have the server explicitly declare the types that it wanted to import instead of using the default of importing all types in node_modules/@types