It turns out that if you try to browserify a file requiring react-tools,
it doesn't work. This is because browserify just visits the require
statements in the file and looks for files in that path.
./ReactCompositeComponent doesn't exist and that's the point that fails.
So the fix is to actually ship each of our CJS modules as individual
files like browserify expects. This should have no negative side effects
- we still only export React (though the rest of our modules are now
actually accessible, which might make it easier to do more with the
module).
The other change here is to move source-map to dependencies since it's
required in the transform code.
Test Plan:
```
$ npm pack .
$ cd /tmp
$ npm install path/to/react-tools-0.3.1.tgz
$ echo "require('react-tools')" > test.js
$ browserify test.js
```
This basically calls `npm pack`, installs the resulting package in a temporary directory, then requires it and attempts to use the .transform method.
Closes#12.
onInput has the advantage that it responds to repeated key events before
onKeyUp and is called when modifying the input without the keyboard
(such as pasting with the mouse).
Test Plan:
Opened the ballmer-peak example and docs homepage in Chrome and checked
that both examples update whenever the text is changed.
'input' is supported in IE9+ and all other browsers according to
https://developer.mozilla.org/en-US/docs/Web/API/window.oninput
Test Plan:
Modified ballmer-peak example to use onInput instead of onKeyUp and
tested that it works properly on latest Chrome.
The bug fixed by this commit prevented the correct parsing of
`var` statements with multiple variables being declared. Instead
of trying to parse a whole 'variable declarations' (a `var`
statement with all its declarations), this visitor now only
parses single 'variable declarators'.