Description of the bug

In a monorepo with multiple versions of postprocessing, it is non-deterministic which version of postprocessing is used when using import {} from 'postprocessing', due to the use of declare module 'postprocessing' {}. This often causes weird type errors where the peer version of THREE's types aren't accepted, even if they are both installed in the same workspace.

removing the declare module wrapper around the types declaration file solves the problem & produces no other side-effects, as having it in the "types" field in the package json automatically assigns the exported types to postprocessing's module.

mayhap i'm wrong with my observation of the side-effects though, is there a historical reason why that declare was used? i'm making this suggestion partially based on the fact that it's been there since the first addition of types in this project, & likely a mistake from my past experience using declare module in shipped types.

To reproduce

https://stackblitz.com/edit/postprocessing-v6-4q7ajeup?file=foo%2Findex.js
after the web container loads, you can see a typescript error in the terminal for renderer

1. create a new npm workspace monorepo with two packages foo & bar
2. in foo's package.json, install "@types/three": "^0.178.0", "postprocessing": "~6.37.6"
3. in bar's package.json, install "@types/three": "^0.152.0", "postprocessing": "~6.31.0"
4. in bar, create a file that imports postprocessing & create a basic scene with THREE's renderer
5. observe type errors when passing in THREE objects into postprocessing

Expected behavior

no type error, correct reference of peer THREE package within the types.

Library versions used

• Three: 0.178.0, 0.152.0 (arbitrarily chosen from an existing project)
• Post Processing: 6.37.6, 6.31.0 (arbitrarily chosen from an existing project)

Desktop

• OS: [e.g. Windows]
• Browser [e.g. Chrome X.X.X.X]
• Graphics hardware: [e.g. NVIDIA]

Mobile

• Device: [e.g. iPhone]
• OS: [e.g. Android]
• Browser [e.g. Firefox X.X.X]