Open adamyeats opened 2 years ago
This issue is stale because it has been open 90 days with no activity. Remove the stale
label, or leave a comment, or this will be closed in 14 days.
Still relevant. We've got Deno/Bun.js support on the long-term roadmap. I recently merged https://github.com/elastic/elasticsearch-js/issues/1281 to explicitly declare the library as a CommonJS package, but improving to include ESM support will be an important step toward multi-runtime compatibility.
FYI: I'm able to use import * as elasticsearch from "npm:@elasticsearch/elasticsearch";
in Deno already without any issues.
This issue is stale because it has been open 90 days with no activity. Remove the stale
label, or leave a comment, or this will be closed in 14 days.
4 months ago it was said it is still relevant
thanks for your patience, @karfau. I was on leave for 2 months, just getting back to addressing open issues now.
This issue is stale because it has been open 90 days with no activity. Remove the stale
label, or leave a comment, or this will be closed in 14 days.
Related to https://github.com/elastic/elasticsearch-js/issues/1281 and https://github.com/elastic/elasticsearch-js/issues/1742.
🚀 Feature Proposal
@elastic/elasticsearch
is currently a CommonJS module. While CommonJS isn't going away any time soon, ECMAScript Modules are very much "the future" of the JavaScript ecosystem. As the community moves in this direction, it may be wise for us to consider moving this library in the same way.To accommodate both CJS and ESM users, we might want to create an ES module wrapper that exports both a CJS and ESM version of the library.
At the very least, as suggested in https://github.com/elastic/elasticsearch-js/issues/1281, it would be good to make the type of the module explicit in
package.json
if we decide to remain with CJS for the time being.Motivation
This will allow the library to work in Deno, and enable asynchronous module loading in Deno and Node.js.