JS SDK needs to support library makers better

[nlacasse]

In npm and browserify, each module gets its own copy of the modules that it depends. This is an issue for the vanadium module because we have many singletons that expect there to be only one copy of vanadium in the process space. So far the ones that i've come across is:

ContextKey
Error Catalog
VOM constructor map.

Also #147

[nlacasse]

cc @asadovsky

[asadovsky]

FWIW: with browserify 10.2.5 and up, if modules A and B require the same symlinked module, they will share the same, single instance of that module. Apparently this is how things work in Node, too.

That doesn't solve the core issue described here, but it helps in some cases. For example, todosapp depends on both syncbase and vanadium, and syncbase itself depends on vanadium. Since we use "npm link" to set up vanadium (as well as syncbase), with browserify 10.2.5 and up, todosapp and syncbase end up sharing the same instance of the vanadium module.

browserify/browserify#1063

[jxson]

I just ran into this as well.

It manifests as a an error log in the console and no error is propagated to the callback, for instance:

var syncbase = require('syncbase');
var service = syncbase.newService('example');
var app = service.app(store.appName);
var context = runtime.getContext();
var permissions = {};

app.create(context, permissions, function onapp(err) {
  if (err) {
    console.log('app.create() failed');
    throw err;
  }

  console.log('app.create() succeeded');
});

Generates the log:

Uncaught Error: app:op: Bad argument: Attempting to look up a value on a context, but the key is not of type ContextKey.
  (anonymous function) @ deferred.js:41
  Item.run             @ browser.js:62
  drainQueue           @ browser.js:33

I was installing the vanadium and syncbase dependencies the same way that npm would by making copies in the correct node_modules directory. My previous target looked like this:

.DELETE_ON_ERROR:
node_modules: package.json
    @npm prune
    @npm install
    @npm install $(V23_ROOT)/release/javascript/core
    @npm install $(V23_ROOT)/roadmap/javascript/syncbase
    @cd node_modules/syncbase && npm install $(V23_ROOT)/release/javascript/core
    @touch node_modules

Once I moved to linking the modules as a temporary workaround things started working properly. This is a pretty serious bug, it will need to be resolved before any kind of release so our modules don't break for users in unexpected ways.

[nlacasse]

I think there's a few things we should do:

1. Stop using x instanceof Context, and switch to x.constructor.name === 'Context'. It's not as strict, but it avoids issues with Context singletons.
2. Give syncbase a peer dependency on vanadium.js, that way we can ensure that the runtime that syncbase gets is a known compatible version.

[jxson]

I like option one. We may want to add a version check as well to ensure the API will work where there might be drift between the different versions...

Another option might be to move syncbase into the vanadium module, then they will be guaranteed to use the same version (not sure how practical this is though...).