We will continue using `bin/jsx-internal`, well, internally.
Note that this version no longer respects `@providesModule`, and it
doesn't do anything special with constants like `__DEV__`, so we can no
longer get to claim that `bin/jsx` can be used to build the core.
I'm happy about this, personally, because it demonstrates the flexibility
of Commoner.
A silent upgrade from graceful-fs v1.2.2 to v1.2.3 (a dependency for both
Commoner and Populist) broke the build process, even though tests were
still passing. The 2.0.0 version fixes whatever was broken, though I won't
pretend to know exactly what the root cause was.
There are other changes I'm sure but the most important is that module
sorting results in deterministic builds.
The biggest win here comes for releases. Previously we had to jump
through hoops to make sure the files we put in bower were the same files
we put on the CDN, were the same files packaged in the Ruby gem, were
the same files we packaged into a zip file, were the same file we used
when create PRs to CDNJS. Rebuilding docs also resulted in conflicting
versions so we had to be careful when committing. This takes away all of
that pain. We can build from the same revision and get the same files.
This behavior is new in Commoner v0.8.3, following the incorporation of
@jeffreylin's `DirWatcher` implementation:
https://github.com/jeffreylin/jsx_transformer_fun/blob/master/dirWatcher.js
Watching directories instead of files reduces the total number of open
files, and copes better with editors that save files by deleting and then
immediately recreating them.
Closes#60.
Closes#71.
If you are using bin/jsx independently, you may need to pass
--follow-requires to it if you rely on its dependency scanning.
Dependency scanning is still a good idea, but it's difficult to make it
work perfectly for everyone the first time they try bin/jsx.
Closes#131.
It turns out that (at least for local development) npm has a long
standing bug where it doesn't recognize changing dependencies stored as
git urls (see https://github.com/isaacs/npm/issues/1727). Luckily npm
understand tarballs and GitHub provides tarballs for every commit, so
the workaround is easy, though unfortunate.
The Commoner upgrade is a big one because it makes bin/jsx no longer
rewrite module identifiers to be relative by default, which should
reduce confusion for people trying to use it as a standalone
transformer.
Closes#80.
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.
