-
-
Notifications
You must be signed in to change notification settings - Fork 32.5k
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
[core] Upgrade dependencies from yarn audit #16625
Conversation
Details of bundle changes.Comparing: 3b6c822...68512f2
|
The last one can't be updated because of
|
90% of the time security issues in dev dependenciens aren't actual issues. Would be nice if we could automate that whole process to keep track of when deps get outdated and what changed so that we can decide if we want to upgrade. |
In this case they don't seem to affect us in any way
There is a bot owned/made by GitHub for this https://github.com/marketplace/dependabot-preview |
I'm testing it on my fork currently but it doesn't seem to pick up anything. It's perfect since we can configure it to only run weekly. I doubt it can pick up that we mix app with library code in the repository though. |
I have personally disabled the GitHub automatic security pull requests on most of my small projects. It's noise. I would be more worried if I was hosting the source of final end-product. In the case of Material-UI, we start to be high-profile, we have to be cautious. However, I agree with @eps1lon. If we had to choose between the two, I think that we should invest our time in keeping the dependencies up to date rather than spending time on dev dependencies security issues. I used to upgrade the dependencies every week. I was enjoying doing it. Time has passed and realized that I was doing it mostly to satisfy my curiosity. A new ritual or a new bot could do it. |
There is a yarn conflict. |
I've enabled dependabot for https://github.com/eps1lon/material-ui/ and will see how this works out. We have to be careful since we mix app and library code. We need to prevent upgrades of library dependencies that only change the lockfile but not the package.json. Some other issues as well. Will test it for a week and then see if there are outstanding issues. It already helps a lot to get automatic updates with links to the changelog. That should already reduce workload by a lot. |
@eps1lon Great. Does the dependabot has an option to batch changes? The n°1 thing I think that we should avoid, is to have a constant flow, every few days, of dependency update on the repository. It would only keep us busy. While we can put our time at better use. |
Yes. live, daily, weekly, monthly. security only and then all sorts of commonds for specific dependencies: eps1lon#15 |
Perfect, so for instance, we could expect a single pull request with all the updates every week 👌 . |
@oliviertassinari I'll get to it 👍
@oliviertassinari There is one PR per dependency
@eps1lon https://www.npmjs.com/package/syncyarnlock |
@merceyz The advantage is that we can more easily isolate which dependency upgrade break what. This was my pain point n°1 in the past when batching the changes manually. From time to time, it was time-consuming to identify which upgrade break what (the last occurrence I remember was related to TypeScript and my lack of knowledge of it, I didn't know if the CI fail was an issue with the typescript engine, the linter or one of the third-party dependencies). But maybe this pain point is marginal to the gain of batching? I don't know. I think that we need to make sure all these PRs, over the course of, let's a 1 month, won't disturb us too much. For instance, https://github.com/react-bootstrap/react-bootstrap/commits/master, it's 37 pull-requests a week they manually accept. That's doesn't look OK. |
Now is the time to adopt conventional commits so you don't have to look at the commits 😄
Rebased |
Interesting, how do you see this commit convention solve pain points we face here? (I don't see the link with dependabot and I'm interested in learning more of the other dimensions it would help us with). |
You said that the commit history doesn't look good with 37 commits from dependabot, the joke was that if you use conventional commits you don't have to look at the commit history to get a changelog.
Would mostly just automate the changelog process, and (IMO) make it easier to see what happened in a commit as people would be forced to be specific. |
Oh, my concern what at 70% with the fact that the React Bootstrap team has reviewed and manually approved, on average, 5 pull requests a day. This sounds like something that keeps them busy, not making them more productive. Could they save this context shift? 30% with the fact that people looking at the change history will see 50% of noise in the commits (we also merge, on average 5 PRs a day). I use the follow hacky script to generate the changelog: Array.from(document.querySelectorAll('.commit'))
.map(node => {
return `- ${node.querySelector('.commit-message a').getAttribute('title').split('\n')[0]} ${node.querySelector('.avatar img').getAttribute('alt')}`;
})
.sort()
.join('\n'); I'm sure it could be improved. I have count that I spend on average 48h a year just to do the release. Spending a days to further automate it would make sense from a business perspective. |
An attempt to make
yarn audit
happier after https://snyk.io/blog/snyk-research-team-discovers-severe-prototype-pollution-security-vulnerabilities-affecting-all-versions-of-lodash/