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

Update dependencies and consider not pinning them #154

Closed
XhmikosR opened this issue Apr 26, 2023 · 8 comments
Closed

Update dependencies and consider not pinning them #154

XhmikosR opened this issue Apr 26, 2023 · 8 comments
Labels
question Further information is requested

Comments

@XhmikosR
Copy link

XhmikosR commented Apr 26, 2023

The way things are right now, consumers cannot get any fixes without a new version here :/

Let alone that the deps cannot be properly deduped in some cases.

@DavidAnson
Copy link
Owner

I should maybe write this down somewhere since it comes up periodically. What I said before is:

All dependency versions are specified exactly because doing otherwise results in inconsistent behavior and surprises in CI, etc..

I stand by that. (I realize transitive dependencies may still be unreliable, but I can only change what I can change.)

Dependency versioning for this package is managed by Dependabot, and I have it configured to run daily for the “next” branch. That branch should always be up to date, but I do not release a new version of the package every time a dependency changes because that happens so frequently.

If there is an especially notable dependency update or a security issue, I will usually try to release. I don’t know of anything right now to justify that, but I am happy to discuss if folks feel otherwise.

If you know of package manager bugs preventing correct de-duplication, please open an issue for them. If you want to forcibly override a dependency version, some package managers support that. Example from yarn: https://classic.yarnpkg.com/en/docs/selective-version-resolutions/

@DavidAnson DavidAnson added the question Further information is requested label Apr 26, 2023
@XhmikosR
Copy link
Author

Thanks for the explanation, I don't share the same opinion, but if it comes up too frequently, maybe you should indeed mention it in Readme. :)

Anyway, please cut a new patch release when possible due to the yaml update.

@XhmikosR XhmikosR closed this as not planned Won't fix, can't repro, duplicate, stale Apr 26, 2023
@DavidAnson
Copy link
Owner

FYI, I am aware of this un-analyzed (by NIST) alert: https://github.com/DavidAnson/markdownlint-cli2/security/dependabot/1

As I understand the issue, it is a denial of service scenario and poses no threat to security. I am more likely to release for this, but it does not seem urgent based on my understanding.

@XhmikosR
Copy link
Author

XhmikosR commented Apr 26, 2023 via email

@DavidAnson
Copy link
Owner

Yes, thank you! I'm not sure this deserves an alert because unhandled exceptions are pretty much always possible. They are already caught and handled here, so I doubt anyone would even notice aside from the corrupt YAML file not being used.

@DavidAnson
Copy link
Owner

FYI, I was going to publish new releases tonight, but didn't get the chance. Tomorrow, probably.

@DavidAnson
Copy link
Owner

Fixed in v0.7.1

@DavidAnson
Copy link
Owner

@XhmikosR FYI that a bunch of projects likely broke this afternoon due to loose versioning allowing a patch-level breaking change into their dependency chain: isaacs/jackspeak#4. As a maintainer, I'd rather not spend my evenings tracking stuff like this down and strict versioning of my own dependencies is the best way I know of to protect myself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants