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

Feature: --age or --filterMeta #5597

Open
1 task
mikicho opened this issue Nov 6, 2022 · 7 comments
Open
1 task

Feature: --age or --filterMeta #5597

mikicho opened this issue Nov 6, 2022 · 7 comments

Comments

@mikicho
Copy link

mikicho commented Nov 6, 2022

Describe the user story
As a developer, I want to update to the latest version that was published at least x days ago.
This gives security tools a chance to check these versions before we consume them.
A relevant issue from npm-check-updates: raineorshine/npm-check-updates#833

Describe the solution you'd like
Add --age or --filterMeta flag to the pnpm update command.

Describe the drawbacks of your solution

  • With age flag, we need to make sure we check against the correct field and make appropriate changes if the field changes in the future (low risk)

Describe alternatives you've considered

  • update to the latest and be exposed to malicious packages.
@zkochan
Copy link
Member

zkochan commented Nov 6, 2022

We kind of already have something similar but only for subdependencies. See the resolution-mode=time-based setting.

@mikicho
Copy link
Author

mikicho commented Nov 6, 2022

Nice setting! But it doesn't cover the problem properly.
IMO, The registry-based attacks will be more common (if not already) in the near future and as a modern package manager we need to be prepared.

@zkochan
Copy link
Member

zkochan commented Nov 6, 2022

I don't agree. Even if you remove the lockfile, your direct dependency will not be updated to the latest version because with this resolution mode, the range will be resolved to the lowest version. So ^1.0.0 will only be resolved to 1.0.0.

And an update is a manual action, so you should do your own research when you do an update. We can probably print the age of the version in the output, when you run pnpm update --latest --interactive.

image

@mikicho
Copy link
Author

mikicho commented Nov 6, 2022

But this way, we introduce a high friction to the update process which result to either a developer won't update the dependencies regularly or will update them to the latest because this is the easiest thing to do.

@zkochan
Copy link
Member

zkochan commented Nov 6, 2022

Well, updating to the latest is the only good choice to make. It is very rare that bug fixes are ported back to previous versions.

@zkochan
Copy link
Member

zkochan commented Nov 6, 2022

I think even if we add an age option, I would skip updates to packages that have younger versions. Updating to a new version that is not the latest one sounds like a bad idea because it may have a regression that was fixed in the newer version.

@mikicho
Copy link
Author

mikicho commented Nov 12, 2022

regression that was fixed in the newer version

@zkochan it may happen, but it isn't common. I'm way more afraid of packages that delete my whole computer or something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants