We may have a better solution for this in the future, but that's the safest thing for now. To fix this problem going forward, we are pinning the react-router dependency in each version of react-router-dom so there is no chance of a version mismatch.
#TYPES REACT ROUTER DOM INSTALL#
So although there were no public API breakages between 4.3.x and 4.4.0, there was a chance that some people could install 2 mismatched versions.
But there was one case that we hadn't considered, which is that technically react-router-dom version 4.3.x could depend on react-router version 4.4, which they can't because of the changes to how we're using our internal context API. We had received tons of feedback over the course of 8 separate beta releases and squashed quite a few bugs, so we felt pretty confident that everything was ready for 4.4 final. So in react-router-dom version 4.3.1 we have a dependency on "react-router": "^4.3.1" (note the ^).Īt the time we released version 4.4 of both packages on Friday, we had been beta testing 4.4 for over 5 months. However, there's one subtle difference between react-router-dom and react-dom, which is that react-router-dom includes react-router as a dependency, not a peer dependency.
This makes it easy for people to know which version of each package they need, and is the same as react-dom and react do. react-router-dom version 4.3.0, it depends on react-router version 4.3.0. In version 4, we have been releasing all react-router* packages in lock step. We have always tried to do versioning as closely as possible to the way the React team does versioning for their packages. However, there was one major consequence which we didn't foresee, and it all boils down to a single character: ^. We originally intended to release React Router version 5 as 4.4, which we actually did last Friday. There are also a few fixes in this release, including support for React.createRef in and support for using React.forwardRef in. Instead of this: // you can now do this: Probably the most significant change here is that instead of requiring individual files from the router, you need to destructure your imports from the main bundle. We've already taken care of that, in both development and production modes. The point is, you won't be building the router as part of your build. We also introduced pre-optimized builds for production, so you don't have to manually set _ENV to production in your build script if you don't want to (though you probably still want to, for other stuff). We switched from publishing multiple files for each build to a single file in v5, just like React itself (we copied their code! 😉). But now all our builds pass all our tests. Before this release we were only running tests on our source code, so there was a chance that our build introduced a bug somewhere.
#TYPES REACT ROUTER DOM FULL#
Other housekeeping items in this release include a complete overhaul to our bundling infrastructure and full test coverage for all bundles we publish. Side note: we have been working on this problem for over 2 years now. Using the new context API in React 16 (we use Jamie Kyle's create-react-context shim for backwards compat with React 15) also allows us to avoid the "update blocking" problem that you may have had to work around in the past. My sincere thanks to Tim Dorr for getting the ball rolling here, and my good friend Jared Palmer for prodding me along. This includes upgrading from using React's legacy context API, as well as eliminating all other warnings. We know that a lot of React Router users are maintaing apps they've built over the last few years using various versions of React 15 or 16 and React Router 4, and we are showing our committment to you with this release. The most significant improvement in v5 is better allaround support for React 16, while maintaining full compatibility with React >= 15. 🎉 Version 5 will pick up where the 4.x roadmap (now the 5.x roadmap) left off.
#TYPES REACT ROUTER DOM CODE#
If you are already using version 4.x, you can use version 5 immediately with zero code changes.
There are no breaking changes in this release. This release is light on features and fixes, and is more focused on stability and compatibility and preparing the library for future releases.
0 kommentar(er)
