Multiple instances of strong-remoting causes assertion error on "sharedClass instanceof SharedClass"
BerkeleyTrue opened this issue · 13 comments
The connector directly depends on strong-remoting, which is a recipe for problems, as it causes multiple instances of the strong-remoting to be loaded in the Node process. See below for an example.
Using loopback-connector-remote 1.0.2, loopback 2.8.0.
Bundling loopback and serving to client. On initiation, my app crashes with Uncaught AssertionError: false == true, not a very helpful error message.
After some investigation, seems like this statement is the cause. Not sure what the solution would be since it seems like sharedClass object is an instance of SharedClass in this case but fails the test.
Wiping my node_modules dir, remove loopback-connector-remote from my package json, and npm installing seemed to fix the issue.
This is caused by the fact that loopback-connector-remote bundles its own copy of strong-remoting and therefore it calls a different copy of SharedClass function than asserted in the strong-remoting copy used by loopback.
We should rework the connector to use the strong-remoting copy installed in the loopback app.
Can this be done by making Strong-Remoting a peer dependency?
Can this be done by making Strong-Remoting a peer dependency?
It will solve the problem in most cases, but not in all of them.
// solved:
(project)
+- loopback
+- loopback-connector-remote
+- strong-remoting
// still a problem
// $ npm install --save loopback
// $ npm install --save loopback-connector-remote
(project)
+- loopback
+- strong-remoting
+- loopback-connector-remote
+- loopback-connector-remote
+- strong-remoting
Just noticed that loopback requires the remote connector. Is it necessary to require the remote connector in my package.json file?
Also, this is how my project is currently structured and it is working fine.
+- loopback
+- loopback-connector-remote
+- strong-remoting
+- loopback-connector-remote
+- strong-remoting.
Is it necessary to require the remote connector in my package.json file?
No. In fact, it's better to NOT include it in your package.json and always use the one provided by loopback. At least until the this issue and #5 are resolved.
I can confirm this is an issue as I just ran into it. I fixed it by running npm dedup... but that is because I was aware of what was going on. It would be quite confusing if you don't know you need to dedup your modules.
Just ran into it this in another project. Due to the nature of the project (we are using rxjs) the error stack trace was reporting it as an error within rxjs and not loopback. Would yall be open to a PR that makes the assert message descriptive, as AssertionError: false == true is extremely unhelpful. I was thinking something along the lines of 'sharedClass not instance of SharedClass, possible duplicate package error' .
Would yall be open to a PR that makes the assert message descriptive, as AssertionError: false == true is extremely unhelpful. I was thinking something along the lines of 'sharedClass not instance of SharedClass, possible duplicate package error' .
👍 ✖️ 💯
@ritch 's solution is much cleaner.
We should still review all places where the remote connector is using strong-remoting and ensure we won't be bitten by the fact that there are multiple SharedClass around.
We should still review all places where the remote connector is using strong-remoting and ensure we won't be bitten by the fact that there are multiple SharedClass around.
Can you create an issue for this if you think its important?