Despite being able to create typings enabling my typescript modules to use function definitions from a third-party javascript module, this approach seems to cause issues for packages importing my module.
To address this concern, I included the necessary typings in a global.d.ts file for my typescript project since pouchdb-collate does not have an @types package...
// global.d.ts
declare module "pouchdb-collate" {
export function toIndexableString(item: any): string;
export function parseIndexableString(indexableString: string): any;
}
While this setup works seamlessly within project A of my monorepo that utilizes pouchdb-collate and has the global.d.ts in its src/, encountering errors arises when importing project A into project B within the same monorepo. This leads to the unavailability of pouchdb-collate typings in project B, resulting in an error like...
../collate/src/index.ts:4:8 - error TS7016: Could not find a declaration file for module 'pouchdb-collate'. '/project/blabla/node_modules/.pnpm/<a href="/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="d5a5baa0b6bdb1b7f8b6bab9b9b4a1b095e2fbe7fbe7">[email protected]</a>/node_modules/pouchdb-collate/lib/index.js' implicitly has an 'any' type.
Try `npm i --save-dev @types/pouchdb-collate` if it exists or add a new declaration (.d.ts) file containing `declare module 'pouchdb-collate';`
Even though there is already a global.d.ts file in the collate/src folder with the correct syntax, providing the proper types when scripts are executed within the folder!
The only solution I found was placing another copy of global.d.ts in project B as well.
Exploring other options, I attempted to create a package C within the monorepo containing a global.d.ts and re-exporting symbols from pouchdb-collate through an index.ts file like...
// modules/collate/src/index.ts
export { parseIndexableString, toIndexableString } from "pouchdb-collate";
This alternative method (aliasing via a package) aims to eventually replace those functions with typescript-optimized versions. However, this strategy also encounters the same issue.
What would be the most effective way for package C to re-export the symbols along with the appropriate typings for this third-party package, ensuring seamless consumption by projects importing package C?