search

dmonad / lib0

Monorepo of isomorphic utility functions
MIT License
347 stars 62 forks source link

Module iso-browser.js does not provide an export named 'default' #9

Closed ronnyroeller closed 4 years ago

ronnyroeller commented 4 years ago

I'm running yjs (13.2.0) in es-dev-server (1.54.1).

I get this error in the Chrome console (85.0.4167.0):

Uncaught SyntaxError: The requested module '../isomorphic.js/iso-browser.js' does not provide an export named 'default'

The error is triggered by this import https://github.com/dmonad/lib0/blob/9e527d97f5a115aca82a6a60b012e061a81e135e/isomorphic.js#L8

https://github.com/dmonad/isomorphic.js/commit/0bee192a679a839f43f75395e70f23d35a2df9f2 seems to have indeed removed the default export.

Not importing the default export solves the error:

import * as iso from 'isomorphic.js'
dmonad commented 4 years ago

Hi @ronnyroeller, sorry you have to experience this issue. I already had many people reporting this issue.

Actually, this is the correct syntax for importing commonjs modules. The whole ecosystem agreed on this (typescript, rollup, broccoli, ..). But es-dev-server still uses a very old version of rollup to bundle modules and even implements a custom transformer to bundle commonjs modules.

I want to provide high-quality javascript modules that work in the browser (using mainstream bundlers like browserify, typescript, rollup, and webpack) and natively in nodejs.

If I would change the import statement to import * as iso from 'isomorphic.js' it would make it invalid code for nodejs (I.e. I wouldn't be able to import the lib0 esm module with node nor would I be able to execute node test.js). At this point it is impossible to write esm code that works in node and in es-dev-server.

Clearly, es-dev-server should bump their dependencies and go with the flow. We really don't need another custom module bundler.

I suggest that you either stop using es-dev-server or open a ticket against them and link to this issue.

FYI: @istvank also reported this issue. I think he ended up bundling Yjs+lib0 into a single esm module file using rollup and then imported that file into his project.

ronnyroeller commented 4 years ago

Thanks for the explanation, @dmonad! Makes a ton of sense.

And thanks for all your great work btw :)

dmonad commented 4 years ago

Welcome :)

LarsDenBakker commented 4 years ago

FYI es dev server isnt a bundler, its using an up to date version of rollup to reuse the plugin for resolving module imports.

It otherwise relies on standard browser behavior for es modules, which doesnt know what to do with commonjs modules.

DeadWisdom commented 3 years ago

es-dev-server isn't doing anything here, it merely maps the name 'isomorphic.js' to the correct url. This is not the correct syntax for the browser. I'm surprised it works in node. In node 15, at least, import * as iso from 'isomorphic.js' works correctly.

Is it currently not possible to use y.js without a bundler?

dmonad commented 3 years ago

isomorphic.js is a commonjs module. The correct way to import commonjs modules is using the import iso from 'isomorphic.js' syntax.

isomorphic.js imports node-native features, if they are available. This must happen dynamically using the require statement.

There is currently no alternative to write isomorphic modules (packages that work in the browser & node and that work as esm & cjs modules). I took great care to make the approach compatible with all bundlers. I don't see a way to support es-dev-server while supporting node-native features if they are available.

Yjs currently requires a bundler when packaged for the browser. Once the maintenance phase of Node.js v10 runs out we can use conditional imports to enable the same feature in a proper way.