0

With the exception of node API usage (fs, http, net...), vanilla js remains executable on any engine. Simple functionality can be relatively easily "plucked" from a packaged module (provided the licensing terms are met), but this gets messy for larger modules.

Is there a straightforward/less-frowned-upon way to use a module in an arbitrary environment? Ideally such a npm2notnpm bridge would be able to interface with the complete module as forked, there is also no expectation to have it work in 100% cases :)

Why?.. the CMS engine we have to work with can execute arbitrary javascript using Spidermonkey engine (on the server); unfortunately that's the only way to build anything functional on the platform. I'd like to be able to leverage available packages as much as possible (cheerio on the wishlist) rather than re-inventing the wheel or copy-pasting code without context.

Oleg
  • 24,465
  • 8
  • 61
  • 91
  • it's a pretty standard pattern already, just re-define exports and module before you eval each package and harvest the objects after you eval. should work 100% with normal commonJS modules... – dandavis Dec 09 '13 at 23:43
  • How much overlap between the Spidermonkey engine and NodeJS is there? If it's a module that's generic and not using NodeJS code, there's a chance it's available elsewhere, like maybe as a bower module. But, it's not clear what kind of code you'd want to use, given the limitations you're already aware of? – WiredPrairie Dec 10 '13 at 01:51

1 Answers1

1

You can use Require.js to load many Common.js packaged modules. Or you could define exports = window and pass that to the module to get access to the module.

http://requirejs.org/docs/commonjs.html

Patrick Gunderson
  • 3,263
  • 17
  • 28
  • Yes. I misunderstood the problem to be moving node modules to spidermonkey-based browsers. If he's able to execute code under spidermonkey standalone I'd need to know what they're using to do that before recommending a potential solution (Rhino?) – Patrick Gunderson Dec 10 '13 at 00:55