2019-09-05 16:04:52 -04:00
|
|
|
import { __ } from 'embark-i18n';
|
2019-05-21 15:30:33 +02:00
|
|
|
import * as fs from "./fs";
|
feat(@embark/core): Auto generate EmbarkJS events
For every provider registered and set with EmbarkJS, auto generate events to inform other modules of the state of the provider.
Any provider that belongs to EmbarkJS (currently Blockchain, Names, Messages, and Storage) will have both a `runcode:<provider name>:providerRegistered` and a `runcode:<provider name>:providerSet` event created automatically when the `CodeRunner` is instantiated.
Once the `registerProvider` code is run through the VM, ie `EmbarkJS.Blockchain.registerProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerRegistered`.
Likewise, once the `setProvider` code is run through the VM, ie `EmbarkJS.Blockchain.setProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerSet`.
Additional updates/fixes with this PR:
* Move `CodeRunner` to TypeScript
* Fix console errors with ENS and Storage due to a recent PR that waits for `code-generator:ready`. The solution here was to ensure that `code-generator:ready` is requested, so that premature events can be handled.
2019-02-21 19:16:39 +11:00
|
|
|
import VM from "./vm";
|
2019-05-21 15:30:33 +02:00
|
|
|
|
|
|
|
export { fs, VM };
|
|
|
|
|
2019-05-02 14:06:11 -05:00
|
|
|
import { Callback, Embark, Events, Logger } /* supplied by @types/embark in packages/embark-typings */ from "embark";
|
2019-05-21 15:30:33 +02:00
|
|
|
|
2019-08-30 15:50:20 -05:00
|
|
|
class CodeRunner {
|
feat(@embark/core): Auto generate EmbarkJS events
For every provider registered and set with EmbarkJS, auto generate events to inform other modules of the state of the provider.
Any provider that belongs to EmbarkJS (currently Blockchain, Names, Messages, and Storage) will have both a `runcode:<provider name>:providerRegistered` and a `runcode:<provider name>:providerSet` event created automatically when the `CodeRunner` is instantiated.
Once the `registerProvider` code is run through the VM, ie `EmbarkJS.Blockchain.registerProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerRegistered`.
Likewise, once the `setProvider` code is run through the VM, ie `EmbarkJS.Blockchain.setProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerSet`.
Additional updates/fixes with this PR:
* Move `CodeRunner` to TypeScript
* Fix console errors with ENS and Storage due to a recent PR that waits for `code-generator:ready`. The solution here was to ensure that `code-generator:ready` is requested, so that premature events can be handled.
2019-02-21 19:16:39 +11:00
|
|
|
private logger: Logger;
|
|
|
|
private events: Events;
|
|
|
|
private vm: VM;
|
2019-08-30 15:50:20 -05:00
|
|
|
|
feat(@embark/core): Auto generate EmbarkJS events
For every provider registered and set with EmbarkJS, auto generate events to inform other modules of the state of the provider.
Any provider that belongs to EmbarkJS (currently Blockchain, Names, Messages, and Storage) will have both a `runcode:<provider name>:providerRegistered` and a `runcode:<provider name>:providerSet` event created automatically when the `CodeRunner` is instantiated.
Once the `registerProvider` code is run through the VM, ie `EmbarkJS.Blockchain.registerProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerRegistered`.
Likewise, once the `setProvider` code is run through the VM, ie `EmbarkJS.Blockchain.setProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerSet`.
Additional updates/fixes with this PR:
* Move `CodeRunner` to TypeScript
* Fix console errors with ENS and Storage due to a recent PR that waits for `code-generator:ready`. The solution here was to ensure that `code-generator:ready` is requested, so that premature events can be handled.
2019-02-21 19:16:39 +11:00
|
|
|
constructor(embark: Embark, _options: any) {
|
|
|
|
this.logger = embark.logger;
|
|
|
|
this.events = embark.events;
|
2019-07-01 16:38:27 -05:00
|
|
|
|
feat(@embark/core): Auto generate EmbarkJS events
For every provider registered and set with EmbarkJS, auto generate events to inform other modules of the state of the provider.
Any provider that belongs to EmbarkJS (currently Blockchain, Names, Messages, and Storage) will have both a `runcode:<provider name>:providerRegistered` and a `runcode:<provider name>:providerSet` event created automatically when the `CodeRunner` is instantiated.
Once the `registerProvider` code is run through the VM, ie `EmbarkJS.Blockchain.registerProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerRegistered`.
Likewise, once the `setProvider` code is run through the VM, ie `EmbarkJS.Blockchain.setProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerSet`.
Additional updates/fixes with this PR:
* Move `CodeRunner` to TypeScript
* Fix console errors with ENS and Storage due to a recent PR that waits for `code-generator:ready`. The solution here was to ensure that `code-generator:ready` is requested, so that premature events can be handled.
2019-02-21 19:16:39 +11:00
|
|
|
this.vm = new VM({
|
|
|
|
require: {
|
|
|
|
mock: {
|
2019-03-17 18:14:54 -05:00
|
|
|
fs,
|
feat(@embark/core): Auto generate EmbarkJS events
For every provider registered and set with EmbarkJS, auto generate events to inform other modules of the state of the provider.
Any provider that belongs to EmbarkJS (currently Blockchain, Names, Messages, and Storage) will have both a `runcode:<provider name>:providerRegistered` and a `runcode:<provider name>:providerSet` event created automatically when the `CodeRunner` is instantiated.
Once the `registerProvider` code is run through the VM, ie `EmbarkJS.Blockchain.registerProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerRegistered`.
Likewise, once the `setProvider` code is run through the VM, ie `EmbarkJS.Blockchain.setProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerSet`.
Additional updates/fixes with this PR:
* Move `CodeRunner` to TypeScript
* Fix console errors with ENS and Storage due to a recent PR that waits for `code-generator:ready`. The solution here was to ensure that `code-generator:ready` is requested, so that premature events can be handled.
2019-02-21 19:16:39 +11:00
|
|
|
},
|
|
|
|
},
|
|
|
|
sandbox: {
|
|
|
|
},
|
|
|
|
}, this.logger);
|
|
|
|
|
|
|
|
this.registerEvents();
|
|
|
|
this.registerCommands();
|
|
|
|
}
|
|
|
|
|
|
|
|
private registerEvents() {
|
2019-08-30 15:50:20 -05:00
|
|
|
// TODO: remove this on once all runcode:register have been converted to commands
|
2019-06-20 19:39:31 -04:00
|
|
|
this.events.on("runcode:register", this.registerVar.bind(this));
|
2019-08-30 15:50:20 -05:00
|
|
|
this.events.setCommandHandler("runcode:register", this.registerVar.bind(this));
|
|
|
|
this.events.setCommandHandler("runcode:whitelist", this.whitelistVar.bind(this));
|
2019-06-20 19:39:31 -04:00
|
|
|
}
|
feat(@embark/core): Auto generate EmbarkJS events
For every provider registered and set with EmbarkJS, auto generate events to inform other modules of the state of the provider.
Any provider that belongs to EmbarkJS (currently Blockchain, Names, Messages, and Storage) will have both a `runcode:<provider name>:providerRegistered` and a `runcode:<provider name>:providerSet` event created automatically when the `CodeRunner` is instantiated.
Once the `registerProvider` code is run through the VM, ie `EmbarkJS.Blockchain.registerProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerRegistered`.
Likewise, once the `setProvider` code is run through the VM, ie `EmbarkJS.Blockchain.setProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerSet`.
Additional updates/fixes with this PR:
* Move `CodeRunner` to TypeScript
* Fix console errors with ENS and Storage due to a recent PR that waits for `code-generator:ready`. The solution here was to ensure that `code-generator:ready` is requested, so that premature events can be handled.
2019-02-21 19:16:39 +11:00
|
|
|
|
2019-06-20 19:39:31 -04:00
|
|
|
private registerCommands() {
|
|
|
|
this.events.setCommandHandler("runcode:getContext", (cb) => {
|
|
|
|
cb(this.vm.options.sandbox);
|
feat(@embark/core): Auto generate EmbarkJS events
For every provider registered and set with EmbarkJS, auto generate events to inform other modules of the state of the provider.
Any provider that belongs to EmbarkJS (currently Blockchain, Names, Messages, and Storage) will have both a `runcode:<provider name>:providerRegistered` and a `runcode:<provider name>:providerSet` event created automatically when the `CodeRunner` is instantiated.
Once the `registerProvider` code is run through the VM, ie `EmbarkJS.Blockchain.registerProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerRegistered`.
Likewise, once the `setProvider` code is run through the VM, ie `EmbarkJS.Blockchain.setProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerSet`.
Additional updates/fixes with this PR:
* Move `CodeRunner` to TypeScript
* Fix console errors with ENS and Storage due to a recent PR that waits for `code-generator:ready`. The solution here was to ensure that `code-generator:ready` is requested, so that premature events can be handled.
2019-02-21 19:16:39 +11:00
|
|
|
});
|
2019-06-20 19:39:31 -04:00
|
|
|
this.events.setCommandHandler("runcode:eval", this.evalCode.bind(this));
|
|
|
|
}
|
|
|
|
|
2019-08-30 15:50:20 -05:00
|
|
|
private whitelistVar(varName: string, cb = () => { }) {
|
|
|
|
// @ts-ignore
|
|
|
|
this.vm._options.require.external.push(varName); // @ts-ignore
|
2019-06-20 19:39:31 -04:00
|
|
|
}
|
feat(@embark/core): Auto generate EmbarkJS events
For every provider registered and set with EmbarkJS, auto generate events to inform other modules of the state of the provider.
Any provider that belongs to EmbarkJS (currently Blockchain, Names, Messages, and Storage) will have both a `runcode:<provider name>:providerRegistered` and a `runcode:<provider name>:providerSet` event created automatically when the `CodeRunner` is instantiated.
Once the `registerProvider` code is run through the VM, ie `EmbarkJS.Blockchain.registerProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerRegistered`.
Likewise, once the `setProvider` code is run through the VM, ie `EmbarkJS.Blockchain.setProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerSet`.
Additional updates/fixes with this PR:
* Move `CodeRunner` to TypeScript
* Fix console errors with ENS and Storage due to a recent PR that waits for `code-generator:ready`. The solution here was to ensure that `code-generator:ready` is requested, so that premature events can be handled.
2019-02-21 19:16:39 +11:00
|
|
|
|
|
|
|
private registerVar(varName: string, code: any, cb = () => { }) {
|
|
|
|
this.vm.registerVar(varName, code, cb);
|
|
|
|
}
|
|
|
|
|
2019-06-20 19:39:31 -04:00
|
|
|
private evalCode(code: string, cb: Callback<any>, tolerateError = false) {
|
feat(@embark/core): Auto generate EmbarkJS events
For every provider registered and set with EmbarkJS, auto generate events to inform other modules of the state of the provider.
Any provider that belongs to EmbarkJS (currently Blockchain, Names, Messages, and Storage) will have both a `runcode:<provider name>:providerRegistered` and a `runcode:<provider name>:providerSet` event created automatically when the `CodeRunner` is instantiated.
Once the `registerProvider` code is run through the VM, ie `EmbarkJS.Blockchain.registerProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerRegistered`.
Likewise, once the `setProvider` code is run through the VM, ie `EmbarkJS.Blockchain.setProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerSet`.
Additional updates/fixes with this PR:
* Move `CodeRunner` to TypeScript
* Fix console errors with ENS and Storage due to a recent PR that waits for `code-generator:ready`. The solution here was to ensure that `code-generator:ready` is requested, so that premature events can be handled.
2019-02-21 19:16:39 +11:00
|
|
|
cb = cb || (() => { });
|
|
|
|
|
|
|
|
if (!code) {
|
|
|
|
return cb(null, "");
|
|
|
|
}
|
|
|
|
|
|
|
|
this.vm.doEval(code, tolerateError, (err, result) => {
|
|
|
|
if (err) {
|
2019-09-05 16:04:52 -04:00
|
|
|
this.logger.error(__("Error running code: %s", code));
|
|
|
|
this.logger.error(err.toString());
|
feat(@embark/core): Auto generate EmbarkJS events
For every provider registered and set with EmbarkJS, auto generate events to inform other modules of the state of the provider.
Any provider that belongs to EmbarkJS (currently Blockchain, Names, Messages, and Storage) will have both a `runcode:<provider name>:providerRegistered` and a `runcode:<provider name>:providerSet` event created automatically when the `CodeRunner` is instantiated.
Once the `registerProvider` code is run through the VM, ie `EmbarkJS.Blockchain.registerProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerRegistered`.
Likewise, once the `setProvider` code is run through the VM, ie `EmbarkJS.Blockchain.setProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerSet`.
Additional updates/fixes with this PR:
* Move `CodeRunner` to TypeScript
* Fix console errors with ENS and Storage due to a recent PR that waits for `code-generator:ready`. The solution here was to ensure that `code-generator:ready` is requested, so that premature events can be handled.
2019-02-21 19:16:39 +11:00
|
|
|
return cb(err);
|
|
|
|
}
|
|
|
|
|
|
|
|
cb(null, result);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
}
|
2019-08-30 15:50:20 -05:00
|
|
|
|
|
|
|
export default CodeRunner;
|