Welcome to part two of a three part series that aims to help you get a jumpstart on new and breaking API changes in the upcoming Node.js v0.12 release. In part one, we pulled out the non-breaking API changes, while in part two he separates out breaking APIs. In part three, Ben Noordhuis details breaking C++ API changes on the fantastic StrongLoop blog.
Because v0.12 is not out yet, this post is largely based on differences between v0.10 documentation and v0.11. Click on an API below to jump to the appropriate section in the post below to learn more.
- rl.setPrompt(prompt)
- process.maxTickDepth removed
- Writable stream emits ‘finish’ on next tick if there was a ‘write()’
- VM
- vm.runInThisContext(code, [options])
- vm.createContext([sandbox])
- vm.isContext(sandbox)
- vm.runInContext(code, contextifiedSandbox, [options])
- vm.runInNewContext(code, [sandbox], [options])
- vm.createScript(code, [filename])
- new vm.Script(code, options)
- script.runInThisContext([options])
- script.runInContext(contextifiedSandbox, [options])
- script.runInNewContext([sandbox], [options])
rl.setPrompt(prompt)
The length argument that is mentioned but not documented in v0.10 doc was removed.
process.maxTickDepth removed
process.maxTickDepth has been removed, allowing process.nextTick to starve I/O indefinitely.
Writable stream emits ‘finish’ on next tick if there was a ‘write()’
In v0.10, write() and end() callbacks might be called after the finish event was emitted. In v0.12 it is emitting finish, but it’s waiting until the next tick, since a write() operation might still potentially be pending.
Here’s an example:
var stream = require('stream');
var util = require('util');
var Peek = function () {
stream.Writable.call(this);
};
util.inherits(Peek, stream.Writable);
Peek.prototype._write = function (chunk, encoding, callback) {
callback();
};
var preview = new Peek();
preview.on('finish', function () {
console.log('finish');
});
preview.write('some text', 'utf-8', function(er) {
console.log('write');
});
preview.end(function() {
console.log('end');
});
console.log('end of tick');
Running this example in node v0.10 and v0.12 produces the following:
$ node-v0.10/bin/node test.js
finish
end of tick
write
end
$ node-v0.12/bin/node test.js
end of tick
write
finish
end
VM
VM modules got bumped from Unstable to Stable.
vm.runInThisContext(code, [options])
vm.runInThisContext() compiles code, runs it and returns the result. Running code does not have access to local scope, but does have access to the current global object.
Example of using vm.runInThisContext and eval to run the same code:
var localVar = 'initial value';
var vmResult = vm.runInThisContext('localVar = "vm";');
console.log('vmResult: ', vmResult);
console.log('localVar: ', localVar);
var evalResult = eval('localVar = "eval";');
console.log('evalResult: ', evalResult);
console.log('localVar: ', localVar);
// vmResult: 'vm', localVar: 'initial value'
// evalResult: 'eval', localVar: 'eval'
vm.runInThisContext does not have access to the local scope, so localVar is unchanged. eval does have access to the local scope, so localVar is changed.
In this way vm.runInThisContext is much like an indirect eval call, e.g. (0,eval)('code'). However, it also has the following additional options:
filename– allows you to control the filename that shows up in any stack traces produced.displayErrors– whether or not to print any errors to stderr, with the line of code that caused them highlighted, before throwing an exception. Will capture both syntax errors from compiling code and runtime errors thrown by executing the compiled code. Defaults totrue.timeout– a number of milliseconds to execute code before terminating execution. If execution is terminated, anErrorwill be thrown.
vm.createContext([sandbox])
If given a sandbox object, will “contextify” that sandbox so that it can be used in calls to vm.runInContext or script.runInContext. Inside scripts run as such, sandbox will be the global object, retaining all its existing properties but also having the built-in objects and functions any standard global object has. Outside of scripts run by the vm module, sandbox will be unchanged.
If not given a sandbox object, returns a new, empty contextified sandbox object you can use.
This function is useful for creating a sandbox that can be used to run multiple scripts, e.g. if you were emulating a web browser it could be used to create a single sandbox representing a window’s global object, then run all <script> tags together inside that sandbox.
vm.isContext(sandbox)
Returns whether or not a sandbox object has been contextified by calling vm.createContext on it.
vm.runInContext(code, contextifiedSandbox, [options])
vm.runInContext compiles code, then runs it in contextifiedSandbox and returns the result. Running code does not have access to local scope. The contextifiedSandbox object must have been previously contextified via vm.createContext; it will be used as the global object for code.
vm.runInContext takes the same options as vm.runInThisContext.
vm.runInNewContext(code, [sandbox], [options])
vm.runInNewContext compiles code, contextifies sandbox if passed or creates a new contextified sandbox if it’s omitted, and then runs the code with the sandbox as the global object and returns the result.
vm.runInNewContext takes the same options as vm.runInThisContext.
Note that running untrusted code is a tricky business requiring great care. vm.runInNewContext is quite useful, but safely running untrusted code requires a separate process.
vm.createScript(code, [filename])
Breaking in v0.12
This method was deprecated (apparently without notice) and replaced by new vm.Script.
new vm.Script(code, options)
Creating a new Script compiles code but does not run it. Instead, the created vm.Script object represents this compiled code. This script can be run later many times using methods below. The returned script is not bound to any global object. It is bound before each run, just for that run.
The options when creating a script are:
filename– allows you to control the filename that shows up in any stack traces produced from this script.displayErrors– whether or not to print any errors to stderr, with the line of code that caused them highlighted, before throwing an exception. Applies only to syntax errors compiling the code; errors while running the code are controlled by the options to the script’s methods.
script.runInThisContext([options])
Similar to vm.runInThisContext but a method of a precompiled Script object. script.runInThisContext runs script’s compiled code and returns the result. Running code does not have access to local scope, but does have access to the current global object.
The options for running a script are:
displayErrors– whether or not to print any runtime errors to stderr, with the line of code that caused them highlighted, before throwing an exception. Applies only to runtime errors executing the code; it is impossible to create a Script instance with syntax errors, as the constructor will throw.timeout– a number of milliseconds to execute the script before terminating execution. If execution is terminated, an Error will be thrown.
script.runInContext(contextifiedSandbox, [options])
Similar to vm.runInContext but a method of a precompiled Script object. script.runInContext runs script’s compiled code in contextifiedSandbox and returns the result. Running code does not have access to local scope.
script.runInContext takes the same options as script.runInThisContext.
script.runInNewContext([sandbox], [options])
Similar to vm.runInNewContext but a method of a precompiled Script object. script.runInNewContext contextifies sandbox if passed or creates a new contextified sandbox if it’s omitted, and then runs script‘s compiled code with the sandbox as the global object and returns the result. Running code does not have access to local scope.
script.runInNewContext takes the same options as script.runInThisContext.