-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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(large-javascript-libraries): delete #12941
Conversation
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 was expecting all our locales to be updated, will that only happen when we do a i18n import?
yeah |
@@ -129,7 +129,6 @@ | |||
"archiver": "^3.0.0", | |||
"browserify": "^17.0.0", | |||
"browserify-banner": "^1.0.15", | |||
"bundle-phobia-cli": "^0.14.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.
shouldn't there be a yarn.lock
change for this? And if there is, why doesn't git add -A && git diff --cached --exit-code
catch it?
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.
ohhh, yarn install --frozen-lockfile
leaves yarn.lock
unchanged. lol whoops
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.
oops. let's remove that
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.
Interesting, --fronzen-lockfile
seems to only have an error exit code when it needs to install new packages, not uninstall. It seems like any change to the yarn.lock
file should trigger that, but I guess at least it's just unused modules sitting there, not missing ones?
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.
The first issue is the situation described by you, where
--frozen-lockfile
succeeds even if there are optimizations to be made (i.e. packages to remove). This behavior is intentional, though there are good arguments to be made that this behavior should be changed. The documentation should definitely be improved here (yarnpkg/yarn#5847), but I don't think it's a bug.
much later...
Just for clarity - was this ever fixed for Classic Yarn (1.x)? Facing this issue in 1.22.5 and I'd rather not have to migrate to v2.
1.x is frozen and will only receive security fixes, so the answer is no.
😐
so nice |
fixes #12296