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
Fix Component Governance alerts #41485
Conversation
ws@^7.2.3, ws@^7.4.5, ws@^7.4.6, ws@~8.2.3: | ||
version "7.5.7" | ||
resolved "https://registry.yarnpkg.com/ws/-/ws-7.5.7.tgz#9e0ac77ee50af70d58326ecff7e85eb3fa375e67" | ||
integrity sha512-KMvVuFzpKBuiIXW3E4u3mySRO2/mCHSyZDJQM5NQ9Q9KHWHWh0NHgfbRMLLrceUK5qAL4ytALJbpRMjixFZh8A== |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm reading this correctly, it looks scary. Does this mean that a package requesting ws
v8.2.3 will instead get v7.5.7❔ If yes, is there a way to map v7.x.y to v7.5.7 but still have v8.2.3 map to itself❔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it does mean that, and I'm not sure if there's a way to achieve that. I'm trying ^
here because I've run into problems with resolving versions using >=
as that often updates things too much and leads to build breaks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to use >=
instead of ^
, after looking at other branches I'm thinking that >=
breaks things less often than I'd thought.
ws@>=7.4.6, ws@^7.2.3, ws@^7.4.5, ws@~8.2.3: | ||
version "8.6.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this is better but now the 7.x.y dependencies are getting updated across a major version boundary. @BrennanConroy is JS testing enough to catch any problems that may cause❔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This version is only used for a single test AFAIK and it's sort of a silly test IMO.
The majority of our tests that use WS actually get WS from https://github.com/dotnet/aspnetcore/tree/main/src/SignalR/clients/ts/signalr which is using 7.4.6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WFM as long as the big ws
version bumps definitely don't break anything
@@ -49,6 +49,7 @@ | |||
}, | |||
"devDependencies": {}, | |||
"resolutions": { | |||
"url-parse": ">=1.5.6" | |||
"url-parse": ">=1.5.6", | |||
"ws": ">=7.4.6" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: This might as well be >=8.6.0
based on the yarn.lock file
Spa-templates are now updated in this PR (CC @mkArtakMSFT @MackinnonBuck) |
@javiercn @MackinnonBuck @HaoK we've got a template test failure after updating dependencies in spa-templates, can you take a look?
|
@wtgodbe |
Hi @RichardSunMS. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context. |
Will also need dotnet/spa-templates#47