recursive-proxy-mock VS patch-package

Let's take a specific example. One of my libraries recursive-proxy-mock is bundled with Rollup. If you take a look at dist/cjs/index.js you can see there is one big file with everything in it, all bundled together. There are named exports for each thing. This can easily have unused code eliminated either via tree shaking or dead code elimination. I've never made a distinction as to which applies in which scenario since both should always be used together. But I guess my point is, a bundled library doesn't need to have any special format which would require a bundlers help to drop dead code.

If you want to check out my build config for my library that sounds very similar in architecture to yours, feel free: https://github.com/CreativeTechGuy/recursive-proxy-mock

Take a look at the recursive-proxy-mock library. The ability to create an object where every property or function "exists" with infinite depth is a really powerful primitive. Not just for providing mock implementations to complex objects for testing, but also for the ability to store and replay operations on another object in the future.

If you are just looking for a TS library config (not related to react) then here's a good example I can share: https://github.com/CreativeTechGuy/recursive-proxy-mock/blob/main/rollup.config.js

In order to allow users to use their device as a controller to adjust the position of the camera and find stars, I use the depreciated DeviceOrientationControls by patching it back into Three. In order for DeviceOrientationControls to function, we need access the user to grant access to their device's orientation. I attempt to gain access to this, alongside their camera, during a previous step of the UX using a custom composable I wrote for this purpose. You can see that permission step in the mockup video above. Once this permission is granted, we can initialize our DeviceOrienationControls with a single line.

If you use Yarn, there’s the `yarn patch` command [1], which lets you maintain patches for your dependencies. Even though I try to upstream patches wherever possible, sometimes you just want to apply a quick patch and move on, especially if the dependency is poorly maintained or even worse, deeply nested in your dependency hierarchy. I use `yarn patch` regularly, it’s one of the main reasons why I moved to Yarn in the first place.

If you’re not using Yarn, there seems to be a similar thing on npm, `patch-package`. [2] I never had to use that though.

[1]: https://yarnpkg.com/cli/patch

[2]: https://www.npmjs.com/package/patch-package

You can use patch-package to edit the part of the library.

patch-package

NPM doesn't have a patch command, but you can use patch-package to achieve the same result.

If there's issue ticket discussing it and someone can fix it, ask for patch file and use patch-package to patch it

You can try this (I highly recommend you to use the Patch Package library to track changes on any external library that you are using. (https://www.npmjs.com/package/patch-package)