Bump stylelint from 16.2.1 to 16.3.1

[dependabot]

Bumps stylelint from 16.2.1 to 16.3.1.

Release notes

Sourced from stylelint's releases.

16.3.1

• Fixed: selector-max-id end positions (#7571) (@​romainmenke).
• Fixed: import errors for configs and plugins omitting /index.js (#7578) (@​ota-meshi).

16.3.0

• Added: ignoreSelectors: [] to selector-max-compound-selectors (#7544) (@​FloEdelmann).
• Added: tally of fixable problems to string and verbose formatters (#7539) (@​m-allanson).
• Added: support for *-deprecation command-line flags of Node.js (#7550) (@​fpetrakov).
• Fixed: false positive CJS deprecation warning for dual-package plugins (#7532) (@​JounQin).
• Fixed: rule-selector-property-disallowed-list false positives for nesting selectors (#7558) (@​romainmenke).
• Fixed: selector-pseudo-*-allowed-list false positives for vendor prefixes (#7525) (@​carlosjeurissen).
• Fixed: report() for index/endIndex zero values (#7565) (@​romainmenke).
• Fixed: selector-max-type end positions (#7518) (@​romainmenke).

Changelog

Sourced from stylelint's changelog.

16.3.1

• Fixed: selector-max-id end positions (#7571) (@​romainmenke).
• Fixed: import errors for configs and plugins omitting /index.js (#7578) (@​ota-meshi).

16.3.0

• Added: ignoreSelectors: [] to selector-max-compound-selectors (#7544) (@​FloEdelmann).
• Added: tally of fixable problems to string and verbose formatters (#7539) (@​m-allanson).
• Added: support for *-deprecation command-line flags of Node.js (#7550) (@​fpetrakov).
• Fixed: false positive CJS deprecation warning for dual-package plugins (#7532) (@​JounQin).
• Fixed: rule-selector-property-disallowed-list false positives for nesting selectors (#7558) (@​romainmenke).
• Fixed: selector-pseudo-*-allowed-list false positives for vendor prefixes (#7525) (@​carlosjeurissen).
• Fixed: report() for index/endIndex zero values (#7565) (@​romainmenke).
• Fixed: selector-max-type end positions (#7518) (@​romainmenke).

Commits

• 2d74e26 16.3.1
• 9b2ca9c Try fixing npm run version on npm run version
• d469bcd Prepare 16.3.1 (#7580)
• b9ae2b2 Bump postcss-import from 16.0.1 to 16.1.0 (#7575)
• 6bbc5f5 Bump np from 10.0.1 to 10.0.2 (#7574)
• a422972 Bump the typescript group with 1 update (#7573)
• f69c57b Fix selector-max-id end positions (#7571)
• 412ae2b Fix import errors for configs and plugins omitting /index.js (#7578)
• e01617e 16.3.0
• 3158781 Fix npm run release (np) error (#7570)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dotsara]

@jgarber623 My apologies for missing this (2 weeks? yikes). It's the first dependabot PR on this repo! 🎉

What do you think is a good way to go about testing the changes? Right now, the marketing site is the only app pulling in stylelint-config-scss (which may not even be doing that for much longer, depending on where we end up vis-à-vis custom properties vs. scss).

Is it even possible to test the marketing site pulling in this branch? Or would we "just" update it here and then go check the marketing site?

(Either way: I don't see anything in the release notes that is concerning.)

[jgarber623]

@dotsara Following up here this morning after our hasty conversation in Slack yesterday afternoon.

My apologies for missing this (2 weeks? yikes).

Certainly no need for apologies. I missed it, too!

Is it even possible to test the marketing site pulling in this branch? Or would we "just" update it here and then go check the marketing site?

The short answer here is "Yes, absolutely!" The less short answer (which I'll get into in depth below) is, "Yes, absolutely! But we probably don't need to."

I'll share here what I shared with you in Slack, but better explained and more public.

The package.json documentation has a lengthy dependencies section that goes over how you define dependencies and their versions/sources. For our purposes, the relevant sub-sub-section is GitHub URLs.

As of version 1.1.65, you can refer to GitHub URLs as just "foo": "user/foo-project". Just as with git URLs, a commit-ish suffix can be included. For example:

{
  "name": "foo",
  "version": "0.0.0",
  "dependencies": {
    "express": "expressjs/express",
    "mocha": "mochajs/mocha#4727d357ea",
    "module": "user/repo#feature/branch"
  }
}

What that means is that we could update CargoSense/cargosense.com's package.json to point to the code in this PR:

- "@cargosense/stylelint-config-scss": "^0.1.0",
+ "@cargosense/stylelint-config-scss": "CargoSense/stylelint-config-scss#dependabot/npm_and_yarn/stylelint-16.3.1",

We would then run yarn install in that project to pick up the change followed by running yarn lint. If everything looked fine, we'd undo the changes on that project and go about our day.

In the past I've used pattern documented in the "Local Paths" sub-sub-sub-sub-section of the documentation. That's been handy for testing out in-development stuff in a package like stylelint-config-scss.

A well, actually.

Okay, so the above info is handy, good to know, and may serve us well in the future. For this PR, though, it probably doesn't matter. Brains are weird and what follows are some details that occurred to me while making coffee this morning. Stupid, stupid brain.

The below gets into some very weedy weeds, so bear with me.

What this PR is updating

The diff shows the changes here are confined to package-lock.json which:

1. Is not included in the package when it's published to npm (see here).
2. Is relevant for development purposes and used for testing and CI stuff.

Merging this PR wouldn't change anything about projects relying on this package (like CargoSense/cargosense.com).

Stylelint is a peer dependency

Node.js dependencies are a nightmare. One part of that nightmare is peerDependencies. I don't know that anyone totally understands this, but from my experience, peerDependencies are used or recommended for packages (like Stylelint) that have plugin systems.

This configuration is (to the best of my understanding) a way to specify that your package (a plugin!) is compatible with a version of the "main" package (Stylelint, in this case) without explicitly requiring it as a dependency. In practice, that's nonsense and super hand wave-y and use of peerDependencies varies across the vast Node.js ecosystem.

Yarn 😑

CargoSense/cargosense.com#196 goes deep on this, but in short: Yarn does not install peer dependencies. On the other hand, npm does. Good grief.

Why's that relevant? Great question. Not a lot in the context of this PR, but it reminded me of that difference in behavior between the two package managers. FWIW, CargoSense/cargosense.com is using Stylelint v16.2.1 (see here). I'm not sure why Dependabot hasn't yet opened a PR on that repo.

But, as noted way up above, the changes in this PR wouldn't force a change in CargoSense/cargosense.com anyway.

---

So what should we do?

1. I think we should still pair up today and try out installing a package from a PR or commit SHA or what have you. That'd be useful to verify that that works as documented.
2. I really think we can merge this PR and move on.
3. I'd like to switch CargoSense/cargosense.com to npm for the reasons outlined in the issue linked above. It's not a high priority, but it should be an "easy" change and would cut back on a small amount of complexity and unpredictability.

[dotsara]

After talking this through with @jgarber623, I understand now that this version bump only impacts this repo during development and not the sites loading this repo as a dependency. 👍🏽

[dependabot]

Superseded by #3.