Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Transitions] Increase minimal version of react-transition-group to 2.5.3 #14612

Merged
merged 1 commit into from
Feb 21, 2019

Conversation

wilcoschoneveld
Copy link
Contributor

I want to update react-transition-group to version 2.5.3 because of a fix for setState while unmounting.

I don't think there are any breaking changes in the version history and I tested the documentation locally, all seems fine.

@wilcoschoneveld
Copy link
Contributor Author

Hmm I just realized that with using material-ui in my project yarn already uses 2.5.3. So the issue is something else. Anyway wouldn't hurt to update the package I think.

@oliviertassinari oliviertassinari added bug 🐛 Something doesn't work new feature New feature or request labels Feb 21, 2019
@oliviertassinari oliviertassinari self-assigned this Feb 21, 2019
Copy link
Member

@oliviertassinari oliviertassinari left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wilcoschoneveld Thanks, I have rebased on the next branch

@oliviertassinari oliviertassinari removed their assignment Feb 21, 2019
@oliviertassinari oliviertassinari merged commit 6a36f8d into mui:next Feb 21, 2019
@oliviertassinari oliviertassinari changed the title [Transitions] Updated react-transition-group to 2.5.3 [Transitions] Increase minimal version of react-transition-group to 2.5.3 Feb 21, 2019
@mbrookes
Copy link
Member

mbrookes commented Feb 21, 2019

Why force the use of the latest version? As a rule we should support the minimum version of a package (and above) that works with Material-UI.

@eps1lon
Copy link
Member

eps1lon commented Feb 21, 2019

Depends on the package. Usually it's better to propagate patches downstream. This way people can rely on bigger packages to vet updates and just have to update a single package to get improvements for various packages.

Whatever we decide on we should be consistent. The current state of having updated versions in the lockfile and earlier versions in the package.json quite dangerous. We might use features of a package introduced in 2.7.0 which is used via lockfile. But if we declare ^2.6.0 in the package.json then this is technically not correct. Any user installing our package might still be using 2.6.0 due to another dependency and now our package fails. Debugging those issues can be very frustrating.

@oliviertassinari
Copy link
Member

oliviertassinari commented Feb 21, 2019

@mbrookes Hard tradeoff. One could argue that it's better to have a site working and slow than not working, the version also has a bundle size reduction pull request by @TrySound.

@oliviertassinari
Copy link
Member

oliviertassinari commented Feb 21, 2019

So far, the strategy has been to only update the dependency version when we need it (new features or bug fixes)

@joshwooding
Copy link
Member

It might be worth adding that the fix above was applied in 2.5.1

@oliviertassinari
Copy link
Member

Correct and 2.5.3 contains the bundle size reduction.

@mbrookes
Copy link
Member

mbrookes commented Feb 22, 2019

I see there was just a similar discussion here: #14602 (review), so sorry for the distraction; but glad to know we're all on the same page.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 Something doesn't work new feature New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants