* Hello 15.6 Release Candidate
**what is the change?:**
We update the versions of all associated React packages when bumping the
version of React.
**why make this change?:**
We want to publish a RC to give folks time to try out the latest version
before it's final.
Why bump the version of every other associated package?
It makes the dependency between them more clear.
There will be cases where we make a fix in React-DOM and it requires
changes in React core. In that case, it will be more clear to people
when we update the versions of both and they remain in sync.
**test plan:**
Visual inspection
**issue:**
https://github.com/facebook/react/issues/9398
* Update a couple more packages versions
**what is the change?:**
Updates version for 'react-dom-factories' package and 'react-addons'
template.
**why make this change?:**
We missed these in the previous commit, which was copying the approach
from https://github.com/facebook/react/pull/9828/files
**test plan:**
Visual inspection, and running the build
**issue:**
https://github.com/facebook/react/issues/9398
* react-create-class -> create-react-class
* Fix issues/bugs introduced by merge conflict resolution
**what is the change?:**
A couple of bugs and holes were introduced when cherry-picking https://github.com/facebook/react/pull/9232 onto the 15.6 branch. This fixes them.
We also needed to add some logic from https://github.com/facebook/react/pull/9399
**why make this change?:**
To keep tests passing and get this change working.
**test plan:**
`yarn test`
**issue:**
https://github.com/facebook/react/issues/9398
* Move component base classes into a single file (#8918)
* More fixes for issues introduced by rebasing
**what is the change?:**
- Remove some outdated 'require' statements that got orphaned in 'React.js'
- Change 'warning' to 'lowPriorityWarning' for 'React.createClass'
- Fix syntax issues in 'React-test'
- Use 'creatReactClass' instead of ES6 class in ReactART
- Update 'prop-type' dependency to use no higher than 15.7 because 15.8 limits the number of warnings, and this causes a test to fail.
- Fix some mixed-up and misnamed variables in `React.js`
- Rebase onto commit that updates deprecation messages
- Update a test based on new deprecation messages
**why make this change?:**
These were bugs introduced by rebasing and tests caught the regressions.
**test plan:**
`yarn test`
**issue:**
https://github.com/facebook/react/issues/9398
* Reset `yarn.lock`
**what is the change?:**
I didn't mean to commit changes to `yarn.lock` except for the `prop-types` and `create-react-class` updates.
**why make this change?:**
To minimize the changes we make to dependency versions.
**test plan:**
`rm -rf node_modules`
`yarn install`
`yarn run build`
`yarn test`
* Run `yarn prettier`
* Run 'prettier' on the v15.6 branch
This is an easy fix and I'd like this branch to be as similar to master
(v16.0) as possible.
* `npm install --save-dev prettier && yarn prettier`
Checking in the updated `package.json` and `yarn.lock` for the 15.6
branch.
Oddly, running `yarn prettier` updated more files. I thought the
previous commit had covered all `prettier` syntax updates. Will commit
the new changes in a separate commit.
* Ran prettier
More syntax updates to get `prettier` checks passing on the `15.6-dev`
branch, and eventually, on 15-stable.
* Tweak eslint ignore comments to get linter passing
Something with running `prettier` moves or changes these comments in a
way that they were no longer being applied. We tweaked them so that both
'prettier' and 'eslint' pass.
- Backport change to enqueueReplaceState. Use new API instead of
enqueueCallback, which is gone in 16.
- Implement isMounted using lifecycles, so we have the option of
removing this later.
Warns when using React.createClass for the first time.
Usages of createClass in tests have been converted to plain JavaScript
classes. Tests that rely on replaceState or isMounted use
updater.enqueueReplaceState and updater.isMounted.
* devDependencies: add core-js and es6-symbol polyfill for tests
* Update Flow and fix issues (#8006)
* Add npm v4.0.0 support (#8082)
* Add support for node v7 (#8135)
* Upgrade ESLint and dependencies, fix new lint errors, switch Travis to Yarn (#8309)
* Update ESLint to 3.10.2
Also pull in fbjs for extending properly, per @zpao. This also disables consistent-return, which has about 80 failing cases in React currently. If we'd like to turn this back on, we should do it separately and fix all the call sites properly (rather than just adding 'return undefined;' everywhere, which adds no value.
Fixes to all existing lint errors plus an update for yarn.lock to follow.
* Update yarn.lock after the eslint update.
* Fix all new eslint failures
Unfortunately I had to add three eslint-disable-next-line instances. All have explanations inline.
* Switch Travis to use yarn instead of npm
* Update all Jest packages to 17.x (#8327)
* Update all Jest packages to 17.x, cache babel-jest transforms
* Remove the caching
Looking at the other builds it doesn't seem to actually be that necessary. The bottleneck is executors, not build time.
* Remove unnecessary package, fix fiber test runner
* Regenerate yarn lockfile
* Update Flow to 0.37.0 (#8608)
Nothing really changes.
* Update to Jest 18 (#8621)
* mockImpl -> mockImplementation
D4329549
* Fixed linting errors
* circle.yml and circleci scripts
* Update Flow and fix issues (#8006)
* Fixed flow errors
* Updated shrinkwrap
* Removed unnecessary change
* Added jest --runInBand flag
* Removed ReactDOMFiber changes
* devDependencies: add core-js and es6-symbol polyfill for tests
* Update Flow and fix issues (#8006)
* Add npm v4.0.0 support (#8082)
* Add support for node v7 (#8135)
* Upgrade ESLint and dependencies, fix new lint errors, switch Travis to Yarn (#8309)
* Update ESLint to 3.10.2
Also pull in fbjs for extending properly, per @zpao. This also disables consistent-return, which has about 80 failing cases in React currently. If we'd like to turn this back on, we should do it separately and fix all the call sites properly (rather than just adding 'return undefined;' everywhere, which adds no value.
Fixes to all existing lint errors plus an update for yarn.lock to follow.
* Update yarn.lock after the eslint update.
* Fix all new eslint failures
Unfortunately I had to add three eslint-disable-next-line instances. All have explanations inline.
* Switch Travis to use yarn instead of npm
* Update all Jest packages to 17.x (#8327)
* Update all Jest packages to 17.x, cache babel-jest transforms
* Remove the caching
Looking at the other builds it doesn't seem to actually be that necessary. The bottleneck is executors, not build time.
* Remove unnecessary package, fix fiber test runner
* Regenerate yarn lockfile
* Update Flow to 0.37.0 (#8608)
Nothing really changes.
* Update to Jest 18 (#8621)
* mockImpl -> mockImplementation
D4329549
* Fixed linting errors
* circle.yml and circleci scripts
* Update Flow and fix issues (#8006)
* Fixed flow errors
* Updated shrinkwrap
* Removed unnecessary change
* Added jest --runInBand flag
* Removed ReactDOMFiber changes
We disabled coverage in Travis because the implementation was crashing ( https://github.com/facebook/react/issues/6290 ). Since we upgraded to Jest 15, the entire coverage implementation is brand new so we should give it another try.
(cherry picked from commit 839697f60c)
I already had to aliasify to have better control over the requires
so we might as well do it everywhere for consistency.
This probably makes it easier to rebase the rollup work too
because aliases seems to be how you solve this in that world.
(cherry picked from commit c8f7215b20)
This copies modules into three separate packages instead of
putting it all in React.
The overlap in shared and between renderers gets duplicated.
This allows the isomorphic package to stay minimal. It can also
be used as a direct dependency without much risk.
This also allow us to ship versions to each renderer independently
and we can ship renderers without updating the main react package
dependency.
(cherry picked from commit 0f004efce2)
* Cut out isomorphic dependencies from the renderers
These files reaches into isomorphic files.
The ReactElement functions are exposed on the React object anyway
so I can just use those instead.
I also found some files that are not shared that should be in
renderers shared.
* Found a few more shared dependencies
renderSubtreeIntoContainer is only used by the DOM renderer.
It's not an addon.
ReactClass isn't needed as a dependency since injection doesn't
happen anymore.
* Use a shim file to load addons' dependencies on DOM
By replacing this intermediate file we can do the lazy loading
without needing any lazy requires. This set up works with ES
modules.
We could also replace the globalShim thing with aliased files
instead for consistency.
* Bundle DOM renderers into their individual UMD bundles
Instead of exposing the entire DOM renderer on the react.js
package, I only expose CurrentOwner and ComponentTreeDevtool which
are currently the only two modules that share __state__ with the
renderers.
Then I package each renderer in its own package. That could allow
us to drop more server dependencies from the client package. It
will also allow us to ship fiber as a separate renderer.
Unminified DEV after before
react.js 123kb 696kb
react-with-addons.js 227kb 774kb
react-dom.js 668kb 1kb
react-dom-server.js 638kb 1kb
Minified PROD after before
react.min.js 24kb 154kb
react-with-addons.min.js 37kb 166kb
react-dom.min.js 149kb 1kb
react-dom-server.min.js 144kb 1kb
The total size for react.min.js + react-dom.min.js is +19kb larger
because of the overlap between them right now. I'd like to see
what an optimizing compiler can do to this. Some of that is fbjs
stuff. There shouldn't need to be that much overlap so that's
something we can hunt. We should keep isomorphic absolutely
minimal so there's no reason for other React clones not to use it.
There will be less overlap with Fiber.
However, another strategy that we could do is package the
isomorphic package into each renderer bundle and conditionally
initialize it if it hasn't already been initialized. That way
you only pay an overlap tax when there are two renderers on the
page but not without it. It's also easier to just pull in one
package. The downside is the versioning stuff that the separate
npm package would solve. That applies to CDNs as well.
ReactWithAddons is a bit weird because it is packaged into the
isomorphic package but has a bunch of DOM dependencies. So we have
to load them lazily since the DOM package gets initialized after.
(cherry picked from commit 8ef00dbb7d)
Nathan Hunzaker
Dan Abramov
Flarnie Marchan
Flarnie Marchan
Dan Abramov
Andrew Clark
Brian Vaughn
Jon Bretman
Andrew Clark
Jack Cross
Ben Alpert
tomocchino
Sebastian Markbage
Paul O’Shannessy
Dmitrii Abramov
Christopher Chedeau
Christoph Pojer
Sebastian Markbåge
Keyan Zhang