Note: This is the first time we're sharing meeting notes publicly. The primary reason we haven't shared these is because we often mix public discussions with matters that are Facebook specific and should not be public. We're really trying to be more open about our development process and what's happening inside the project so moving forward, we'll be sharing meeting notes. While most of us do work at Facebook, we're committed to this being an open project - for now we'll filter out the private notes from the public notes. Hopefully we can make it possible for these meetings to be open to any who wish to attend.
Attendees:
- @zpao
- @sebmarkbage
- @spicyj
- @jeffmo
- @fkling shipped react-docgen. It's being used by fixed-data-table and the upcoming react-native website
- @jeffmo shipped ES6 module support to Flow
- @zpao started work on some improvements to jstransform in order to replace react-tools. RFC is up in a PR.
There was an XSS hole in HackerOne. It was directly related to their use of React, though it was not an XSS hole in React itself. There was some discussion about what we might be able to do to prevent this sort of thing. @sebmarkbage filed #3473 to discuss and see where we can end up.
@sebmarkbage and @zpao presented a plan for versioning which would hopefully allow for sane consumption of React and React components via npm. The proposed plan would still follow semver rules, but we would start making use of the major version number.
We would add deprecation warnings in X.Y releases. We would also add replacement APIs at the same time. X+1.0 would have the deprecated APIs removed. We could also add completely new APIs in minor versions (eg, the new update API being discussed).
It is ultimately very similar to what we do now, except instead of shipping a 0.X+1 release with deprecation notices and 0.X+2 with APIs removed, we have the major version number to work with.
There was some discussion about whether or not adding a warning to an API still fits into the "behavior change" rules of semver.
One big impetus of this is that we want a sane way for people to be able to specify React as a peerDependency, with the primary and suggest route being to support across 1 major version (14). As deprecation warnings are added and addressed that can be updated (14.3). We'll have an "EOL" for each major version which would be conveniently tagged on npm. If all warnings from the EOL are addressed then you would be compatible with the next major version and the React dependency can be specified like this: 14.5 - 15.
Again, this would be very similar to the evolutionary approach we've taken to deprecating and warning. In the current scheme, components may specify their dependency like 0.11 - 0.13.
No immediate actions are being taken, but as we approach the next release, we'll come back to this.
The combination of supporting CommonJS and providesModule has caused some problems with React Native. We may need to stop stop supporting providesModule in the near future, but there are some things we need to change first to continue supporting React Native. One main concern is the way it overrides implementations of certain React modules.
There are a few ideas (splitting React into a react-core module, then react and react-native can depend on that and inject implementations; moving all of react-native overrides into the react codebase and doing some runtime detection).
Combined with the desire for Facebook to open source some more front-end code and make it easier for consumers to use common libraries (eg react/lib/invariant) we probably need to ship some more core libraries to npm and figure out how to make that work. It's tricker than it seems on the surface.
Thanks for providing these notes publicly. I look forward to following the project develop in the open.