Update dependencies and consider not pinning them

[XhmikosR]

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]

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/

[XhmikosR]

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.

[DavidAnson]

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]

Definitely not urgent, it happens only on specific scenarios only. I'm just used to zero issues after npm install, so I thought I'd bring it to your attention in case you missed it.

…

On Wed, Apr 26, 2023, 19:26 David Anson ***@***.***> wrote: 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. — Reply to this email directly, view it on GitHub <#154 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACVLNOIINYZKBDAXIFCWSTXDFEENANCNFSM6AAAAAAXMQK43M> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[DavidAnson]

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]

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

[DavidAnson]

Fixed in v0.7.1

[DavidAnson]

@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.