Importing OSC-js from ES module does not work

[olange]

I would like to import OSC from a Web Component in a web app (that, in browser), using the ES module import syntax:

import { OSC } from "osc-js";

const osc = new OSC();
osc.open({ host, port });

You would assume I have added the module as dependency of my package.json and did run npm install to retrieve the osc-js package from the NPM registry:

  …
  "dependencies": {
    "osc-js": "^2.0.2",
   …
  },

The build of OSC-js version 2.0.2 currently does not support module imports. Its build uses a version
of the UMD wrapper, which contains a common bug, the incorrect detection of browser global in strict mode implied by module imports (see umdjs/umd#125).

I am unfamiliar with the build process; naively, I would think it is a matter of updating the UMD wrapper that the bundler is using to its latest version – as the above mentioned UMD issue was fixed and merged on 13.10.2017.

[olange]

Many thanks for the osc-js library. We're successfully using it in our @petitatelier/three-web-components/three-camera web component.

I used following workaround to load OSC:

1. Add a <script src="../node_modules/osc-js/lib/osc.min.js"></script> element in the HTML page that bootstraps the web app (demo);
2. Reference OSC in global scope with the self keyword:

const websocketPlugin = new self.OSC.WebsocketClientPlugin();
const osc = new self.OSC( { plugin: websocketPlugin });
osc.open({ host, port });

However, it would be nice if osc-js could simply be imported by the web component itself, so users won't need to worry about adding (add forgetting to add!) one other <script src="…"> to every page using the web component.

[adzialocha]

Thank you @olange! I updated the project dependencies (#39), including a new version of rollup which contains the fixed umd global variable detection (rollup/rollup#2594):

diff --git a/lib/osc.js b/lib/osc.js
index 63ba18a..c41ea1d 100644
--- a/lib/osc.js
+++ b/lib/osc.js
@@ -1,8 +1,8 @@
 (function (global, factory) {
   typeof exports === 'object' && typeof module !== 'undefined' ? module.exports = factory() :
   typeof define === 'function' && define.amd ? define(factory) :
-  (global.OSC = factory());
-}(this, (function () { 'use strict';
+  (global = global || self, global.OSC = factory());
+}(this, function () { 'use strict';

Will merge this soon after a few more tests and new features.

[olange]

Hi @adzialocha, many thanks for the update of the dependencies! I confirm that your update of Rollup allows to import OSC-js with ES6 module import syntax.

I checked out the chore/update-dependencies branch, did a build with npm run build and copied the whole osc-js directory to my @petitatelier/data-streams/node_modules.

I removed the <script src="../node_modules/osc-js/lib/osc.min.js"></script> from main HTML page of my project and replaced it with following constructs:

import "osc-js";

const plugin = new self.OSC.WebsocketClientPlugin();
this.osc = new self.OSC({ plugin });

[adzialocha]

Great! Thank you @olange for the report. I merged the changes, bumped the version and published it (https://github.com/adzialocha/osc-js/releases/tag/v2.0.3).

[olange]

Many thanks!! 👍😺

[olange]

Note: with this fix, the OSC-js library lives in global scope after that import "osc-js" statement.

I guess an additional ES module build should be produced next to the UMD/AMD build, to allow to load the OSC library in module scope instead of global scope.

I am not familiar with Rollup, but I stumbled upon an example in the que-etc/resize-observer-polyfill library; in its rollup.config.js, it defines two build steps:

{
  …  
  output: [{
        name: 'ResizeObserver',
        file: pkg.main,
        format: 'umd'
    }, {
        file: pkg.module,
        format: 'es'
    }],
   …
}

Then in package.json, it uses the main field and module field to distinguish the two builds:

{
  …
  "main": "dist/ResizeObserver.js",
  "module": "dist/ResizeObserver.es.js",
  …
}

Finally I guess your module would need to have a named and default export, which Rollup would use as different entry points to the two builds.

Sorry for these many speculative observations, as of today I never produced such alternative builds. I am using ES modules / import syntax first hand. I will try to use Rollup on my own library, to produce these alternative builds. May be I will then contribute a more constructive PR to your library 🤓