-
Notifications
You must be signed in to change notification settings - Fork 7.3k
createScript, __filename and require with relative paths #2525
Comments
This is my unlucky way to figure out |
I've updated the vm documentation in 465e22e. Re: running node.js code in a sandbox, why don't you use child processes? |
I don't need separate processes, just more control on script execution context. This is for RailwayJS framework. |
Maybe you can suggest some solution for my use case? I need to run some code in sandbox with ability to
|
The vm functions do not use the module system. If I were you, I'd try to do this by hijacking the module loader stuff from It's internal, and mostly undocumented, so you'll just have to RTFS in node's lib/module.js, I'm afraid. But it's also extremely stable, and very unlikely to ever change again. An approach like this might be a start (untested, most likely has bugs) // railway.js
var Module = require("module").Module
var path = require("path")
var target = path.resolve(__dirname, "target.js")
var vm = require("vm")
var ctx = { railway: "stuff" }
var mod = new Module(target, module) // I forget if the parent ref is a module or a path string...
ctx.module = mod
ctx.__filename = target
ctx.__dirname = path.dirname(target)
vm.runInNewContext("module.load(__filename)", ctx, target) |
Thanks for answering. For my special case it's ok to not use createScript but a specialized version of function requireCode(code, pathToCode) {
var vm = require("vm");
var path = require("path");
var Module = require("module").Module;
var filepath = path.resolve(process.cwd(), pathToCode);
var filename = path.basename(filepath);
var dirname = path.dirname(filepath);
var cachedModule = Module._cache[filepath];
if (cachedModule) {
return cachedModule.exports;
}
var mod = new Module(filepath, module);
Module._cache[filepath] = mod;
mod.filename = filepath;
mod.paths = Module._nodeModulePaths(dirname);
mod._compile(code, filepath);
mod.loaded = true;
return mod.exports;
} It loads/compiles |
As per nodejs#2525 a bunch of WGs are renamed from iojs-* to nodejs-*. Update the WORKING_GROUPS.md to match. Note specifically iojs-cn and iojs-tw were renamed to nodejs-zh-CN and nodejs-zh-TW respectively. Fixes: nodejs/node#3247 PR-URL: nodejs/node#3634 Reviewed-By: James M Snell <jasnell@gmail.com>
As per nodejs#2525 a bunch of WGs are renamed from iojs-* to nodejs-*. Update the WORKING_GROUPS.md to match. Note specifically iojs-cn and iojs-tw were renamed to nodejs-zh-CN and nodejs-zh-TW respectively. Fixes: nodejs/node#3247 PR-URL: nodejs/node#3634 Reviewed-By: James M Snell <jasnell@gmail.com>
As per nodejs#2525 a bunch of WGs are renamed from iojs-* to nodejs-*. Update the WORKING_GROUPS.md to match. Note specifically iojs-cn and iojs-tw were renamed to nodejs-zh-CN and nodejs-zh-TW respectively. Fixes: nodejs/node#3247 PR-URL: nodejs/node#3634 Reviewed-By: James M Snell <jasnell@gmail.com>
As per nodejs#2525 a bunch of WGs are renamed from iojs-* to nodejs-*. Update the WORKING_GROUPS.md to match. Note specifically iojs-cn and iojs-tw were renamed to nodejs-zh-CN and nodejs-zh-TW respectively. Fixes: nodejs/node#3247 PR-URL: nodejs/node#3634 Reviewed-By: James M Snell <jasnell@gmail.com>
As per nodejs#2525 a bunch of WGs are renamed from iojs-* to nodejs-*. Update the WORKING_GROUPS.md to match. Note specifically iojs-cn and iojs-tw were renamed to nodejs-zh-CN and nodejs-zh-TW respectively. Fixes: nodejs/node#3247 PR-URL: nodejs/node#3634 Reviewed-By: James M Snell <jasnell@gmail.com>
As per nodejs#2525 a bunch of WGs are renamed from iojs-* to nodejs-*. Update the WORKING_GROUPS.md to match. Note specifically iojs-cn and iojs-tw were renamed to nodejs-zh-CN and nodejs-zh-TW respectively. Fixes: nodejs/node#3247 PR-URL: nodejs/node#3634 Reviewed-By: James M Snell <jasnell@gmail.com>
@WolfgangKluge This worked for me because of a CLI include trying to
I've been using this in conjunction with:
To ensure includes of all types are getting the right relative paths; |
As mentioned in #439, the
filename
parameter ofcreateScript
,runInNewContext
(and all the vm.* - members) is informational only (not as stated in the docs "as if it were loaded from filename"). So the question is, how to solve something likewhere
subtest.js
is a file insubfolder
.The relative path to
./subtest.js
cannot be resolved, because current module filename still points to the current test file (and not tofileInSubfolder.js
).I also tried it with
Module.wrap
, but I don't know, what I should provide asmodule
-parameter. Is there a documentation forwrap
(or examples)?The text was updated successfully, but these errors were encountered: