Reimplement options as es6 class CompileOptions.

CommandOptions extend CompileOptions with commander-specific
features.
Add tests for CompileOptions and CommandOptions.
Our current approach to options passes global values through module instance variables
combined with passing them as arguments. Chaos ensues. We need to pick one of these three.
Passing arguments from the API provides the most control and flexibility. We may continue
to use the global deeper in the call stack, after we are below the API calls. 
fromString was part of the interface because it was accessed via
options.fromString();

 However I agree with the minimizing interfaces. I divided options into
Options and CommandOptions so we did not need it bin/traceur.

But we can't load es6 modules like CommandOptions into eg test-utils
because we have no way to tell nodejs which files to transcode on the fly
via makeDefault() and which ones to just load.
We could compile CommandOptions to commonjs then
require('../../build/node/CommandOptions.js').
We could convert test-utils.js to es6 (mainly removing require() I guess.




On Thu, Jul 24, 2014 at 1:41 PM, Erik Arvidsson <notifications@github.com>
wrote:

> In src/CompileOptions.js:
>
> >
> > -/**
> > - * Takes a string and parses it and sets the options based on that
> > - * string.
> > - */
> > -function fromString(s) {
> > -  fromArgv(s.split(/\s+/));
> > -}
> > +  /**
> > +   * Takes a string and parses it and sets the options based on that
> > +   * string.
> > +   */
> > +  static fromString(s) {
>
> fromString was not exported in this file before. Now it is part of the
> public interface. Seems like we should minimize the interfaces as much as
> we can.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/google/traceur-compiler/pull/1202/files#r15371328>.
>