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

feat(jsii): enforce peer dependencies #294

Merged
merged 2 commits into from
Nov 6, 2018
Merged

feat(jsii): enforce peer dependencies #294

merged 2 commits into from
Nov 6, 2018

Conversation

eladb
Copy link
Contributor

@eladb eladb commented Nov 6, 2018

If a jsii module exposes a type from a dependency in it's public API,
jsii now enforces that this dependency is also defined as a "peer"
instead of a normal dependency.

This tells npm that if a user of this module already
installed a compatible verison of this dependency in their
closure, npm will pick the one installed by the user (as a peer)
instead of fetching another version.

jsii will also flag these dependencies as "peer" in the jsii spec. At the
moment, this won't have implications on generated language packages,
but in environments that have support for peer dependencies, we should
make sure the module's metadata reflects this idea as well.

A utility called "jsii-fix-peers" is included. It will inspect .jsii
and package.json and will add "peerDependencies" to package.json
for all dependencies that have types in the public API.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

If a jsii module exposes a type from a dependency in it's public API,
jsii now enforces that this dependency is also defined as a "peer"
instead of a normal dependency.

This tells npm that if a user of this module already
installed a compatible verison of this dependency in their
closure, npm will pick the one installed by the user (as a peer)
instead of fetching another version.

jsii will also flag these dependencies as "peer" in the jsii spec. At the
moment, this won't have implications on generated language packages,
but in environments that have support for peer dependencies, we should
make sure the module's metadata reflects this idea as well.

A utility called "jsii-fix-peers" is included. It will inspect .jsii
and package.json and will add "peerDependencies" to package.json
for all dependencies that have types in the public API.
@rix0rrr
Copy link
Contributor

rix0rrr commented Nov 6, 2018

<3 that you're adding the attribute it to the jsii manifest, but </3 that it's called "peer". Feels like very NPM-centric terminology. How about talking about "public" vs "private" dependencies, or "interface" vs "implementation" dependencies?

@@ -436,7 +441,7 @@
"type": {
"collection": {
"elementtype": {
"fqn": "@scope/jsii-calc-lib.Number"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a regression !

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, just merge issue. Fixing.

@RomainMuller
Copy link
Contributor

I agree with @rix0rrr that the "peer" name is not ideal, but I disagree with the suggestions as they would seem to imply deeper semantics...

@eladb
Copy link
Contributor Author

eladb commented Nov 6, 2018

@rix0rrr I think it's okay to be npm-centric in the jsii manifest because the source /is/ package.json and is a key part of the jsii model. Since peer dependencies are a complex topic, I feel "latching on" to the "peer" semantics of NPM at least gives the user an entrypoint to understand what's going on. Otherwise, we would need to either reproduce all the documentation ourselves or just tell people "this is like 'peer dependencies' in npm", which then, we might as well, just call "peer".

@eladb eladb merged commit 1753910 into master Nov 6, 2018
@eladb eladb deleted the benisrae/peer-deps branch November 6, 2018 16:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants