search

mdx-js / mdx

Markdown for the component era
https://mdxjs.com
MIT License
17.72k stars 1.14k forks source link

[remark-mdx] Relax package.json dependency versions #1267

Closed berickson1 closed 3 years ago

berickson1 commented 4 years ago

Subject of the feature

Relax package.json dependency versions

Problem

Consumers of packages that define babel as a dependency (like remark-mdx) are forced to pull in a newer version of babel with updating this package. The package.json specifies an individual version of babel that can be used instead of a semver range. Without pulling in the latest version of this module, we're stuck on an older version of babel by default (7.10.5) (due to yarn lockfile de-duplication yarn-deduplicate --strategy fewer). After pulling the latest update of this module, we're forced to update to babel 7.11.1.

Expected behavior

When updating remark-mdx (and other packages), we, as the package consumer, should be able to pick a compatible version of babel with the library instead of being required to select a specific version. If babel were to have a critical update/bug fix, we'd either need to manually change dependency version resolution or wait for this package to update/publish. Likewise, if a bug is introduced in babel and we pulled it in by updating this module, we'd need to downgrade this module.

I would expect your package.json for something like babel to be: "@babel/core":"^7.9.0" (possibly some version slightly higher if there's a good reason) instead of "@babel/core":"7.9.0"(in the latest case I realize it's 7.11.1, just providing an example)

Alternatives

Caret, tilda or range versions for downstream dependencies. Ideally any solution would allow the consumer a bit more flexibility to upgrade/downgrade/manage their own dependencies without having to override module version resolution.

wooorm commented 4 years ago

I’m personally in favor of what you propose, but several other core contributors specifically want it this way, see: https://github.com/mdx-js/mdx/issues/865.

berickson1 commented 4 years ago

I'd argue that yarn/npm lock files protect from random breakages in existing projects. The biggest concern is that if any module you depend on has a vulnerability (and mdx packages haven't updated yet), there's little recourse for a consumer of mdx to upgrade it without doing explicit version pinning. Forcing an update of mdx to resolve a downstream vulnerability potentially introduces additional risks for projects as well.