How to support other run times/environments?

[ShawnTalbert]

I think the current status is:

• we are writing code in CommonJS module syntax
• We try to not break existing usage it by linting the production code for ES5
• There are no tests for a setup other then node.
• Most likely the maintainers do not have enough knowledge about such setups, which would be required create test setups. PRs are welcome.

Ongoing suggestions:

• Rhino/Graal:
  • How to support other run times/environments? #214 (comment)
  • How to support other run times/environments? #214 (comment)
• UMD: How to support other run times/environments? #214 (comment)
• ES Modules: xmldom can not be imported from ES modules #316
• Deno: Document Deno example #232

To suggest support for another specifc env create an issue or PR.

Background

This was an issue that has been converted into a discussion, not so happy with that step anymore.
But want to preserve this discussion for the overall topic.

Original issue test:

I'm trying to get this working in a Rhino environment (or Graal would work too)

I notice the lib/ files assume an environment where exports is defined. As far as I know that's not the case for Rhino or Graal by default?

The readme mentions this work sin Rhino so I must be missing something?

p.s. sorry to file an issue for this as it's perhaps not a bug but I didn't see any other forum.

[ShawnTalbert]

As a workaround I put AMD wrappers around the code (which provides an exports). The Rhino environment I'm in uses AMD as the module system.

Since AMD tries to play nice with CommonJS I think the workaround is successful, but did mean I had to modify the source, which is sad.

Perhaps a good solution would be to have some standard 'auto detection' of the module system in use like many other libraries do to make them work in both the Browser/NodeJS/elsewhere automatically?

For example, TypeScript emits something like the following boilerplate code for UMD modules that seem to play nicely in both CommonJS and AMD environments.

(function (factory) {
    if (typeof module === "object" && typeof module.exports === "object") {
        var v = factory(require, exports);
        if (v !== undefined) module.exports = v;
    }
    else if (typeof define === "function" && define.amd) {
        define(["require", "exports", "...other dependencies here..."], factory);
    }
})(function (require, exports) {
  // main code here
});

https://github.com/umdjs/umd

[joestringer]

If it helps, I used xmldom here with Rhino 1.7.12: SteelAlloy/BTE-tools@09b63f3

This relies on commit 8f02868 of xmldom, otherwise xmldom would fail at runtime as described in the commit message.

[ShawnTalbert]

Thanks @joestringer but I don't see how that addresses the module system issue. Maybe your Rhino 1.7.12 environment wasn't using a module system or am I missing something from the commit you linked? The Rhino environment I run code in also has an AMD module constraint that perhaps is different than your setup.

[karfau]

@ShawnTalbert I'm closing this issue as wontfix, feel free to reopen and/or add more information.

[karfau]

I think the question is not really answered/resolved, so I decided to convert the issue into a discussion.
I think the current status is:

• We try to not break it by linting the production code for ES5
• There are no tests for a setup.
• We don't have any maintainers/contributors that know enough about such setups, to at least have some basic test configured. PRs are welcome.
• It is totally unclear what versions of Rhino/Graal we should/need to support to not break downstreams.

[ShawnTalbert]

My understanding is this isn't really a Rhino/Graal issue - it's about including boilerplate code that would help the library work with a variety of different module loaders regardless of what runtime those module loaders are in.

I tried to make this point in an earlier comment, but not sure it was clear.

Many (most?) libraries meant to be used across different runtime environments have some boilerplate code for handling different module systems. I referred to UMD above because it attempts to handle the situation elegantly for the most common module systems used in nodejs and browser.

[karfau]

You are right. But the same thing applies.
We need to have people that have at least a rough idea what needs to be done and add some tests so we don't break it again.
Even if it means to add dev dependencies or things to github actions only for the purpose of checking that this integration works as expected.

[karfau]

I updated the discussion title accordingly

[karfau]

@brodybits recently added Deno to the discussion by opening #232
I closed this issue for now so that all related discussion can be in this thread. (Reopened to discuss specific environments in specific issues.)

[karfau]

ES module support is discussed in #316