Closed farnabaz closed 1 year ago
Hi! It seems some of the things asked in the template are missing? Please edit your post to fill out everything.
You won’t get any more notifications from me, but I’ll keep on updating this comment, and remove it when done!
Thanks, — bb
Base: 100.00% // Head: 100.00% // No change to project coverage :thumbsup:
Coverage data is based on head (
f51a785
) compared to base (14fc569
). Patch coverage: 100.00% of modified lines in pull request are covered.
:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
Hi, this change does nothing. Semver already pulls changes in. You don’t need to update things in package.json
s.
Indeed, but to do so, users need to do clean install. Updating package.json
is a good thing to ensure that users will not encounter issues like this:
No I don’t believe it is: you are getting the updated version. Otherwise you wouldn’t get this error. Publishing a new version here doesn’t change that: you already have the new version
How do you produce this error? How do you have different versions of mdast-util-to-hast
? What package manager are you using that results in this unstable tree?
The project uses yarn.
The reason behind this is that another package (not rehype-remark
) uses latest version of mdast-util-to-hast
in its package.json
but remark-rehype
has old version. So when we update the other package we will have two versions of mdast-util-to-hast
in yarn lock.
Unless:
package.json
)Here is yarn lock file before clean-install:
mdast-util-to-hast@^12.1.0:
version "12.2.5"
resolved "https://registry.yarnpkg.com/mdast-util-to-hast/-/mdast-util-to-hast-12.2.5.tgz#91532ebd929a7def21585034f7901eb367d2d272"
integrity sha512-EFNhT35ZR/VZ85/EedDdCNTq0oFM+NM/+qBomVGQ0+Lcg0nhI8xIwmdCzNMlVlCJNXRprpobtKP/IUh8cfz6zQ==
dependencies:
"@types/hast" "^2.0.0"
"@types/mdast" "^3.0.0"
mdast-util-definitions "^5.0.0"
micromark-util-sanitize-uri "^1.1.0"
trim-lines "^3.0.0"
unist-builder "^3.0.0"
unist-util-generated "^2.0.0"
unist-util-position "^4.0.0"
unist-util-visit "^4.0.0"
mdast-util-to-hast@^12.2.6:
version "12.3.0"
resolved "https://registry.yarnpkg.com/mdast-util-to-hast/-/mdast-util-to-hast-12.3.0.tgz#045d2825fb04374e59970f5b3f279b5700f6fb49"
integrity sha512-pits93r8PhnIoU4Vy9bjW39M2jJ6/tdHyja9rrot9uujkN7UTU9SDnE6WNJz/IGyQk3XHX6yNNtrBH6cQzm8Hw==
dependencies:
"@types/hast" "^2.0.0"
"@types/mdast" "^3.0.0"
mdast-util-definitions "^5.0.0"
micromark-util-sanitize-uri "^1.1.0"
trim-lines "^3.0.0"
unist-util-generated "^2.0.0"
unist-util-position "^4.0.0"
unist-util-visit "^4.0.0"
If you see no point in updating package.json
I can understand, the issue can resolve simply by updating lock file. I thought that updating package.json
for remark-rehype
in a good thing to do. Feel free to close this 🙂
In yarn v1 de-duplicatation is a bit broken, not just with this package, but across everything. I'd recommend using https://github.com/scinos/yarn-deduplicate#readme to resolve unnecessary duplicates.
As a general policy unified and remark intentionally choose wider version ranges to allow for more de-duplication of more than just the very latest version.
Hi! This was closed. Team: If this was merged, please describe when this is likely to be released. Otherwise, please add one of the no/*
labels.
Packages updating their dependencies as you suggest actually cause the issue you’re describing.
The yarn lockfile locks a dependency specification to a resolved dependency version. This is different for example from npm, which locks where inside node_nodules
to store a resolved dependency. Yarn will initially try to deduplicate dependencies, but on subsequent installs, it absolutely refuses to update these locked dependencies. As a result of this, yarn duplicates dependencies.
If packages keep updating their dependencies as per this PR, that means over time yarn will lock many different ranges to different versions instead of deduplicating. This is also the reason why yarn lockfiles and node_modules
in a project tend to grow over time, regardless of when a project is started.
As @ChristianMurphy stated, You can use yarn-deduplicate
to deduplicate your dependencies. Still, this doesn’t update them beyond the most recent version specified in the lockfile.
In order to update a dependency, remove the entry from yarn.lock
manually, then run yarn install
.
In order to update a dependency, remove the entry from
yarn.lock
manually, then runyarn install
.
And if you want to automate keeping the lockfile up-to-date and well maintained. Consider leveraging renovate bot (https://docs.renovatebot.com/) with the lockfile maintenance option enabled (https://docs.renovatebot.com/configuration-options/#lockfilemaintenance) Which asks renovate to regularly open a PR to refresh the lockfile, to de-duplicate and update versions.
Renovate is a good suggestion.
As an alternative you could create a GitHub workflow that deletes yarn.lock
, runs yarn install
, optionally autofixes new issues arising from your linter, commits and pushes these changes to a branch, creates a PR, and merges automatically if CI for that PR succeeds.
Initial checklist
Description of changes
Upgrade project dependencies to latest version. Since a new version of
mdast-util-to-hast
is released, and it contains changed regarding theState
it is convenient to upgrade this module to prevent conflict between two versions and prevent unexpected issues.Also, I removed
package.json
from dependencies since it has no use in the package and it is deprecated by author.