search

quadstorejs / quadstore

A LevelDB-backed graph database for JS runtimes (Node.js, Deno, browsers, ...) supporting SPARQL queries and the RDF/JS interface.
https://github.com/quadstorejs/quadstore
MIT License
203 stars 14 forks source link

Revise support for ES modules #97

Closed jacoscaz closed 3 years ago

jacoscaz commented 4 years ago

PR #96 and the work that stemmed from it got me to have a deeper look at the state of ES modules in node.js and whether it’s worth publishing both CJS and ES code within the same package as I had originally planned.

There’s currently an issue with ES - CJS compatibility that causes named imports not to work when importing a CJS module into an ES module. This comes from the fact that CJS exports are only known at run time as opposed to parse time for ES exports. AFAIU, this is also why tree-shaking can only be done reliably on ES modules. This seems unlikely to be easily solved.

However, as we definitely have dependencies that do not offer ES alternatives, there’s no way for our entire dependency tree to become ES-only in the near future. This begs the question of whether it’s worth shipping the ES and CJS builds of quadstore within the same NPM package.

As it stands, the ES build is not usable in Node as named imports are breaking under Node >= 14. We could fix that by deconstructing default exports but that would break tree-shaking, which is one of the very reasons why we looked at ES modules.

Furthermore, it looks like Node’s resolution process doesn’t look at the “module” property of package.json files, forcing us to use “exports” declaration which I don’t particularly like as they can conflict with referencing TS typings.

As things stand, I would temporarily get rid of the ES build and figure out how to do this properly in version 8.

List of dependencies and their availability as ES modules

jacoscaz commented 3 years ago

This has been open for 5 months but the situation with our dependencies remains unchanged. However, our bundle size did decrease significantly mainly due to a decrease in dependency count and the packaging of quadstore-comunica in bundled form, diminishing the need to support tree-shaking while bundling. Will close this for now.