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.

Sign up for GitHub

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

Jump to bottom

Peer dependencies #1137

Closed
eladb opened this issue Dec 18, 2019 · 1 comment
Closed

Peer dependencies #1137

eladb opened this issue Dec 18, 2019 · 1 comment
Labels
closed-for-staleness effort/medium Medium work item – a couple days of effort feature-request A feature should be added or improved. module/tools Issues related to the JSII toolkit p2

Comments

@eladb
Copy link
Contributor

eladb commented Dec 18, 2019

🚀 Feature Request

jsii should allow specifying a dependency as only a peer dependency without requiring that it will also be defined in the dependencies section. Peer dependencies are legitimate and in fact seem to be needed to allow implementing 3rd party CDK modules that can actually be used with multiple versions of the CDK.
@eladb eladb added the feature-request A feature should be added or improved. label Dec 18, 2019
RomainMuller added a commit that referenced this issue Dec 18, 2019
@RomainMuller
fix(pacmak): generated dependencies are arbitrary
e335466 
The dependency statements generated in the Java, .NET and Python
packages generated by `jsii-pacmak` were not reflecting the dependency
statement modeled on the source package. In certain pathological cases,
such as Python, the dependency declaration was often more permissive
than what the source package allowed, resulting in surprising behavior
as well as difficult to troubleshoot problems.

This updates several elements involved in this problem:
1. The `jsii` compiler no longer carries declarations of the entire
  (transitive) dependency closure of the package into the `.jsii` file.
  Instead, only direct dependencies are represented. This is fine
  because `jsii` already demands that all assembliesof which a type is
  re-exported be declared (at least) as a `peerDependency`, and the
  change also ensures that `peerDependency` declarations are considered
  in the same way that regular `dependencies` are.
2. The version statements in the `dependencies` section of the `.jsii`
  file no longer contains the "compile-time resolved" version number,
  but the actual SemVer expression declared in the package's source.
3. `jsii-pacmak` renders the declared SemVer range in the relevant form
  for the target being generated.

Fixes #676
Related to #1137
RomainMuller added a commit that referenced this issue Dec 18, 2019
@RomainMuller
fix(pacmak): generated dependencies are arbitrary
009ebeb 
The dependency statements generated in the Java, .NET and Python
packages generated by `jsii-pacmak` were not reflecting the dependency
statement modeled on the source package. In certain pathological cases,
such as Python, the dependency declaration was often more permissive
than what the source package allowed, resulting in surprising behavior
as well as difficult to troubleshoot problems.

This updates several elements involved in this problem:
1. The `jsii` compiler no longer carries version information for
  transitive dependencies of the assembly in the `dependencyClosure`
  property, and instead only carries the `targets` configuration for
  those.
2. The version statements in the `dependencies` section of the `.jsii`
  file no longer contains the "compile-time resolved" version number,
  but the actual SemVer expression declared in the package's source.
  Also, the `targets` object was dropped (only the SemVer range
  statement remains), as this incurred needless duplication of the
  target configuration (in `dependencies` and `dependencyClosure`).
3. `jsii-pacmak` renders the declared SemVer range in the relevant form
  for the target being generated.

Fixes #676
Related to #1137
RomainMuller added a commit that referenced this issue Dec 19, 2019
@RomainMuller
fix(pacmak): generated dependencies are arbitrary
10adcd9 
The dependency statements generated in the Java, .NET and Python
packages generated by `jsii-pacmak` were not reflecting the dependency
statement modeled on the source package. In certain pathological cases,
such as Python, the dependency declaration was often more permissive
than what the source package allowed, resulting in surprising behavior
as well as difficult to troubleshoot problems.

This updates several elements involved in this problem:
1. The `jsii` compiler no longer carries version information for
  transitive dependencies of the assembly in the `dependencyClosure`
  property, and instead only carries the `targets` configuration for
  those.
2. The version statements in the `dependencies` section of the `.jsii`
  file no longer contains the "compile-time resolved" version number,
  but the actual SemVer expression declared in the package's source.
  Also, the `targets` object was dropped (only the SemVer range
  statement remains), as this incurred needless duplication of the
  target configuration (in `dependencies` and `dependencyClosure`).
3. `jsii-pacmak` renders the declared SemVer range in the relevant form
  for the target being generated.

Fixes #676
Related to #1137
@RomainMuller RomainMuller mentioned this issue Dec 19, 2019
Merged
mergify bot added a commit that referenced this issue Dec 27, 2019
@RomainMuller @mergify
fix(pacmak): generated dependencies are not consistent with source np…
03221fe 
…m module (#1141)

* fix(pacmak): generated dependencies are arbitrary

The dependency statements generated in the Java, .NET and Python
packages generated by `jsii-pacmak` were not reflecting the dependency
statement modeled on the source package. In certain pathological cases,
such as Python, the dependency declaration was often more permissive
than what the source package allowed, resulting in surprising behavior
as well as difficult to troubleshoot problems.

This updates several elements involved in this problem:
1. The `jsii` compiler no longer carries version information for
  transitive dependencies of the assembly in the `dependencyClosure`
  property, and instead only carries the `targets` configuration for
  those.
2. The version statements in the `dependencies` section of the `.jsii`
  file no longer contains the "compile-time resolved" version number,
  but the actual SemVer expression declared in the package's source.
  Also, the `targets` object was dropped (only the SemVer range
  statement remains), as this incurred needless duplication of the
  target configuration (in `dependencies` and `dependencyClosure`).
3. `jsii-pacmak` renders the declared SemVer range in the relevant form
  for the target being generated.

Fixes #676
Related to #1137

* pr review feedback actions

* add missing file

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
@SomayaB SomayaB added the module/tools Issues related to the JSII toolkit label Jan 7, 2020
@MrArnoldPalmer MrArnoldPalmer added the effort/medium Medium work item – a couple days of effort label Feb 12, 2020
@andreialecu andreialecu mentioned this issue Feb 22, 2021
Closed
@MrArnoldPalmer MrArnoldPalmer removed their assignment Jun 28, 2021
@github-actions
Copy link
Contributor

This issue has not received any attention in 2 years. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

@github-actions github-actions bot added closing-soon This issue will automatically close in 4 days unless further comments are made. closed-for-staleness and removed closing-soon This issue will automatically close in 4 days unless further comments are made. labels Jun 29, 2023
@github-actions github-actions bot closed this as completed Jul 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
closed-for-staleness effort/medium Medium work item – a couple days of effort feature-request A feature should be added or improved. module/tools Issues related to the JSII toolkit p2
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@eladb @MrArnoldPalmer @SomayaB