Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Document the peerDependenciesMeta in the package.json #1247

Closed
abdonrd opened this issue May 5, 2020 · 7 comments
Closed

[FEATURE] Document the peerDependenciesMeta in the package.json #1247

abdonrd opened this issue May 5, 2020 · 7 comments
Labels
Enhancement new feature or improvement

Comments

@abdonrd
Copy link

abdonrd commented May 5, 2020

I cant find info about the peerDependenciesMeta field in the package.json:

https://docs.npmjs.com/files/package.json

References

It was mentioned at the npm blog here:

https://blog.npmjs.org/post/186983646370/npm-cli-roadmap-summer-2019

New features likely to land on the 6.x branch:

Add support for the peerDependenciesMeta field. (#224)

Also here in the changelog:

https://github.com/npm/cli/releases/tag/v6.11.0

Also the release announcement:

https://npm.community/t/release-6-11-0/9572

@abdonrd
Copy link
Author

abdonrd commented May 26, 2020

Any news? Thanks in advance!

@jrylan
Copy link

jrylan commented Sep 7, 2020

Formal documentation on this feature would be great. I know npm 7+ is going back to the behavior of installing peerDependencies for you if they are not already in your package.json. Now I'm left wondering how that works when a peer dependency is marked as optional in peerDependenciesMeta.

Edit: I've confirmed locally that peerDependencies marked as optional using peerDependenciesMeta are auto-installed.
I've opened this issue at npm/rfcs: npm/rfcs#221

wincent added a commit to liferay/liferay-frontend-projects that referenced this issue Oct 5, 2020
This isn't _strictly_ necessary, but it is an accurate description of
the requirements of the project. We go with the range of "^3.6.3" to
match the lowest range that we're currently using in any project (which
is found in liferay-js-toolkit), to minimize the risk of introducing
duplicates in a consuming project.

If you have a ".ts" file in your project, you are going to have
`typescript` in your `devDependencies`, and our `overrides`
configuration is going to use `@typescript-eslint/parser`, which in turn
is going to require `typescript`, transitively, in
`@typescript-eslint/typescript-estree` here:

https://github.com/typescript-eslint/typescript-eslint/blob/c5ffe8833da7875e82953de117b0abe6fa8a60b0/packages/typescript-estree/src/parser.ts#L2

And all will work, even though `@typescript-eslint/typescript-estree`
doesn't explicitly declare its hard dependency on `typescript` in its
package.json:

https://github.com/typescript-eslint/typescript-eslint/blob/c5ffe8833da7875e82953de117b0abe6fa8a60b0/packages/typescript-estree/package.json#L41-L49

But if you don't have any ".ts", then you shouldn't need to have
`typescript` in your dependency graph, and we won't use
`@typescript/eslint-parser`. So, it makes sense for us to call this an
`peerDependency` and mark it as `optional` as per these posts:

- https://medium.com/@noamgjacobsonknzi/what-is-peerdependenciesmeta-acea887c32dd
- npm/cli#1247

(Note that the `peerDependenciesMeta` field isn't documented yet.)

You could also argue that this should be under `optionalDependencies`:

https://docs.npmjs.com/files/package.json#optionaldependencies

But I think "optional peer" comes closer to the reality here.
`optionalDependencies` is for things that you can add, but the package
should work if they're not there. That's not the case here. The package
won't work if you have ".ts" files but no `typescript`.

Related: #91 (comment)
wincent added a commit to liferay/liferay-frontend-projects that referenced this issue Oct 5, 2020
This isn't _strictly_ necessary, but it is an accurate description of
the requirements of the project. We go with the somewhat unsatisfying
range of "*" to to minimize the risk of introducing duplicates in a
consuming project. At the moment, we're using v4+ in this monorepo,
3.9.7 in liferay-portal, and the lowest range that we're currently using
in any other project is "^3.6.3" (in liferay-js-toolkit). In the future,
we should be able to converge on v4+.

If you have a ".ts" file in your project, you are going to have
`typescript` in your `devDependencies`, and our `overrides`
configuration is going to use `@typescript-eslint/parser`, which in turn
is going to require `typescript`, transitively, in
`@typescript-eslint/typescript-estree` here:

https://github.com/typescript-eslint/typescript-eslint/blob/c5ffe8833da7875e82953de117b0abe6fa8a60b0/packages/typescript-estree/src/parser.ts#L2

And all will work, even though `@typescript-eslint/typescript-estree`
doesn't explicitly declare its hard dependency on `typescript` in its
package.json:

https://github.com/typescript-eslint/typescript-eslint/blob/c5ffe8833da7875e82953de117b0abe6fa8a60b0/packages/typescript-estree/package.json#L41-L49

But if you don't have any ".ts", then you shouldn't need to have
`typescript` in your dependency graph, and we won't use
`@typescript/eslint-parser`. So, it makes sense for us to call this an
`peerDependency` and mark it as `optional` as per these posts:

- https://medium.com/@noamgjacobsonknzi/what-is-peerdependenciesmeta-acea887c32dd
- npm/cli#1247

(Note that the `peerDependenciesMeta` field isn't documented yet.)

You could also argue that this should be under `optionalDependencies`:

https://docs.npmjs.com/files/package.json#optionaldependencies

But I think "optional peer" comes closer to the reality here.
`optionalDependencies` is for things that you can add, but the package
should work if they're not there. That's not the case here. The package
won't work if you have ".ts" files but no `typescript`.

Related: #91 (comment)
@abdonrd
Copy link
Author

abdonrd commented Oct 11, 2020

Any news?

@jrylan
Copy link

jrylan commented Oct 11, 2020

@abdonrd there is a PR here that is not yet merged: #1822

@wheresrhys
Copy link

Is peerDependenciesMeta deprecated in favour of optionalDependencies?

@ljharb
Copy link
Collaborator

ljharb commented Nov 18, 2020

@wheresrhys they're entirely different, albeit similar. optionalDependencies means, if the dep fails to install, don't fail the overarching install. peerDependenciesMeta allows you to provide extra information about peer deps, and marking one "optional" means "it's not an error if it's missing".

@wheresrhys
Copy link

Thanks. I had to read that through a few times to grasp it, but I think I've got it now.

This distinction really needs documenting properly. I've just had a PR submitted wheresrhys/fetch-mock-jest#22 where the submitter almost certainly wants peerDependenciesMeta but has used optionalDependencies.

I'd be happy to help, but maybe best as a non-expert reviewer as I don't think I have the familiarity needed to actually write the docs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement new feature or improvement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants