Creating FRP from separate lib

[dakom]

I ran into a quirky bug in the following scenario:

Core app imports 2 libs: sodium and helpers

helpers also imports sodium, but uses rollup to exclude it on the build (e.g. when the app runs, the only instantiation of sodium itself should be via the one that's bundled into the core app)

However, if helpers creates new primitives, like a new StreamSink and sends it back to the core app for use - things get wonky.

Is this expected behavior? As a casual observation, it makes sense since Sodium does all the memory management, and an external lib is somehow still external - but I just wanted to kick the tires and see if maybe there's something wrong in the packaging system.

On a practical level, I changed the helpers to expect a pre-created sink as an argument - so it's not a big deal. Though we should document it if these are the genuine mechanics.

[clinuxrulz]

Feels like there is two sodium libraries both with their own global scope. Mixing sodium objects across two different global scopes can cause issues with ranks and memory management, leading to leaks and streams firing in the wrong order.

Could UMD modules be used so both pieces of code are talking to the same sodium in the same global scope?

[clinuxrulz]

What I have in mind is if the sodium library was loaded into window.sodium and .d.ts type definition files are constructed to access that same global sodium from separate packaged pieces of code.

Similar to threeJS. You can just install the type definitions without the library "@types/threejs". And have all independent packaged code access the same threejs included 1st via a script tag.

[clinuxrulz]

Better late than never:
This guy has a work around. (But for webpack)
webpack/webpack#2134 (comment)