How to support other run times/environments? #214
Replies: 7 comments 4 replies
This comment has been hidden.
This comment has been hidden.
-
|
As a workaround I put AMD wrappers around the code (which provides an 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
}); |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@ShawnTalbert I'm closing this issue as wontfix, feel free to reopen and/or add more information. |
Beta Was this translation helpful? Give feedback.
-
|
I think the question is not really answered/resolved, so I decided to convert the issue into a discussion.
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
You are right. But the same thing applies. |
Beta Was this translation helpful? Give feedback.
-
|
I updated the discussion title accordingly |
Beta Was this translation helpful? Give feedback.
-
|
@brodybits recently added Deno to the discussion by opening #232 |
Beta Was this translation helpful? Give feedback.
-
|
ES module support is discussed in #316 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I think the current status is:
Ongoing suggestions:
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 whereexportsis 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.
Beta Was this translation helpful? Give feedback.
All reactions