Build system overhaul

[CactusPuppy]

This PR does a lot of things at once:

• Switches the source code to TypeScript to make it easier to understand what the data being passed around looks like
• Introduces the use of ESLint for code styling
• Builds the final OverPy executable bundle with esbuild instead of a homebrewed build system to introduce source maps for far easier debugging
• Removes obfuscation directives entirely. Obfuscation no longer works in OW2's Workshop editor, and was also a complete pain to maintain anyways.

TODO:

• Finish porting all extension functionality
• Complete moving all VS Code extension files to root level
• Properly build extension without miscellaneous junk files (see Why a .vscodeignore file? Use the files property instead microsoft/vscode-vsce#12)
• Introduce unit tests (Jest?) (no longer planned)
• Introduce behavior testing (documented at https://code.visualstudio.com/api/working-with-extensions/testing-extension) (no longer planned)
• Replace vm2 with a different sandboxed JS interpreter
• Add Prettier in a Husky pre-commit hook to enforce code styling

[Zezombye]

Does that not lead back to the security issue (since you can now do shit like console.log.prototype I guess) ?

[CactusPuppy]

No, from my understanding JS Interpreter does not allow access to the prototype of a function passed in in this manner. This is the recommended method for passing in a function, so unless that breaks the sandbox, this should not be an issue.

[CactusPuppy]

From the JS-Interpreter documentation:

Additionally, API calls may be added to the interpreter's global object during creation. Here is the addition of alert() and a url variable:

var myCode = 'alert(url);';
var initFunc = function(interpreter, globalObject) {
  interpreter.setProperty(globalObject, 'url', String(location));

  var wrapper = function alert(text) {
    return window.alert(text);
  };
  interpreter.setProperty(globalObject, 'alert',
      interpreter.createNativeFunction(wrapper));
};
var myInterpreter = new Interpreter(myCode, initFunc);

Alternatively, API calls may be added to an object:

var myCode = 'robot.forwards(robot.fast);';
var initFunc = function(interpreter, globalObject) {
  // Create 'robot' global object.
  var robot = interpreter.nativeToPseudo({});
  interpreter.setProperty(globalObject, 'robot', robot);

  // Define 'robot.fast' property.
  interpreter.setProperty(robot, 'fast', 99);

  // Define 'robot.forwards' function.
  var wrapper = function forwards(speed) {
    return realRobot.forwards(speed);
  };
  interpreter.setProperty(robot, 'forwards',
      interpreter.createNativeFunction(wrapper));
};
var myInterpreter = new Interpreter(myCode, initFunc);

This code essentially acts like the last example, but substituting console for robot and the log function for forwards.

[Zezombye]

Right, since it's a wrapper you can't do JS shenanigans. Pretty neat

[netux]

I ain't reading all that, but it does compile Ana PB successfully 🎉

The only thing I noticed is that OverPy doesn't include comments from Values in @Conditions anymore:

(In
https://github.com/JinkoMinko/ana-paintball/blob/827626c696392a4b139cf62984a9fb60daf55561/medals.opy#L136)

but it does include them for Values in the actions block, like in here: https://github.com/JinkoMinko/ana-paintball/blob/dfa292183722614709f363a767505f13b705c032/nano.opy#L8

[CactusPuppy]

I ain't reading all that, but it does compile Ana PB successfully 🎉

The only thing I noticed is that OverPy doesn't include comments from Values in @Conditions anymore: (In https://github.com/JinkoMinko/ana-paintball/blob/827626c696392a4b139cf62984a9fb60daf55561/medals.opy#L136)

but it does include them for Values in the actions block, like in here: https://github.com/JinkoMinko/ana-paintball/blob/dfa292183722614709f363a767505f13b705c032/nano.opy#L8

Resolved in a91e4e5