Mdx: Relax dependency versions

[NMinhNguyen]

Subject of the feature

Relax dependency versions.

Problem

See https://github.com/mdx-js/mdx/pull/858#issuecomment-563336666. Essentially, when installing an MDX package such as @mdx-js/mdx, I would rather not have a pinned version of any @babel/* dependencies installed - this causes duplicate versions and can plausibly lead to subtle bugs. If you look at https://unpkg.com/@mdx-js/mdx@1.5.1/package.json, you'll see @babel/core 7.6.2 gets installed, as well as fixed versions for @babel/plugin-syntax-jsx and @babel/plugin-syntax-object-rest-spread.

Expected behavior

Dependencies should use carets (e.g. ^7.6.2).

Alternatives

Yarn users are able to use things like Yarn resolutions but it's not ideal to have to resort to resolutions.

/cc @JounQin @johno

[timneutkens]

Based on our experience at @zeit not using pinned deps will lead to the package randomly breaking a lot.

[NMinhNguyen]

@timneutkens I think that pinning versions can give a false sense of security - e.g. all Babel deps use carets for their own deps, so you get non-deterministic installs with every new install without a lockfile anyway.

[timneutkens]

@NMinhNguyen it greatly reduces the vector of breakage though.

[NMinhNguyen]

@timneutkens Perhaps you could consider relaxing some common (and actively maintained and reliable) build tooling dependencies that aren’t really meant to be duplicated (like Babel)?

[JounQin]

I'm not a fan of pining versions of depeendencies neither personally.

https://github.com/1stG/configs/blob/master/packages/renovate-config/package.json#L21

And I'm using https://github.com/atlassian/yarn-deduplicate on postinstall lifecycle to ensure correct dependencies.

[NMinhNguyen]

@JounQin with the currently published packages, an older version of @babel/core gets installed because my other dependencies have a dependency on a later version of @babel/core (using a caret), so it’s unavoidable even with deduplication.

[JounQin]

@JounQin with the currently published packages, an older version of @babel/core gets installed because my other dependencies have a dependency on a later version of @babel/core (using a caret), so it’s unavoidable even with deduplication.

@NMinhNguyen You can try resolutions like https://github.com/mdx-js/eslint-mdx/blob/master/package.json#L46-L51 temporarily.

[NMinhNguyen]

@JounQin yup, I actually reference Yarn resolutions in the issue description :)

[JounQin]

@mdx-js/maintainers What do you think then?

[JounQin]

@johno @wooorm Would you like to join this thread?

[wooorm]

I don’t have an opinion on this. In my own projects, I prefer loose ranges, but I can see why this project would do it differently, and understand Tim’s view.

[JounQin]

@wooorm Can you explain in details? IMO we should move all devDependencies inside workspaces into root package.json to reduce conflicts with yarn-deduplicate. And then we can run yarn workspace gatsby-example start for development.

[wooorm]

I understand what you mean, but I don’t have an opinion on this (I personally dislike yarn, lerna, monorepo versioning).
As I don’t have an opinion on this, I trust Tim’s and John’s opinions.

[JounQin]

none of these dependencies make it to the client since it's build tooling

@johno @wooorm As the issue's thread, this is not correct.

[johno]

Dev dependencies are now at the root level. We will also be keeping pinned versions for now in order to avoid subtle bugs and upstream changes.

Thanks all!