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

build(deps): pin ALL dependency versions in package.json files 2023-07-24 #2574

Merged
merged 1 commit into from
Aug 11, 2023

Conversation

petermetz
Copy link
Contributor

@petermetz petermetz commented Jul 24, 2023

  1. Replaced all tilde and caret characters in package.json
    files with nothing so that all versions are pinned down
    for safety and stability of the build/publishing process.
  2. On top of just removing the tildes and carets, I also upgraded the
    declared versions to whatever their caret upgrades would've been (e.g.
    performed minor upgrades on all the versions). This is important because
    this is how we achieve parity with the actual dependencies that were used
    by the code prior to this PR - this also highlights why it is necessary to
    have reproducible builds and pinned versions: because without it one has
    no actual answer to the question of "So what dependencies does your code
    need to function exactly?"
  3. Removed the jasmine types from the root package because they
    were causing build problems with the weaver tsc compilation.
    The proper, longer term solution here is to make the weaver packages'
    tsc configuration on-boarded to the monorepo structure, but I did not want
    to blow up this commit to be 10x the current size just because of this.
    I opened a couple of issues regarding this.
  4. I added protobufjs as a dev dependency to the API server package because
    artillery suddenly stopped working when grpcjs was upgraded and it was
    complaining that one of its dependencies (protobufjs) cannot be imported.
  5. I added the protocol buffer compiler to the dev container.
  6. Added a new VSCode extension to the list of recommended ones because
    I found it extremely useful while performing the minor upgrades in the
    dozens of package.json files (100+ dependencies in total). Why? Because
    all the other tooling that exists in the NodeJS ecosystem assumes that
    doing major upgrades on dependencies in batch is the only thing needed.
    None of the tools are able to do a minor upgrades only mass upgrade
    operation, even the ones that claim this as a feature do not have it.
  7. I synced the list of recommended VSCode extensions to the dev container
    definition file so that the same extensions get installed automatically
    in the container as well.

Fixes #2571

Signed-off-by: Peter Somogyvari [email protected]

Copy link
Contributor

@jagpreetsinghsasan jagpreetsinghsasan left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@izuru0 izuru0 left a comment

Choose a reason for hiding this comment

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

LGTM

@petermetz petermetz force-pushed the petermetz/issue2571 branch 9 times, most recently from cefe5db to 1e729e7 Compare August 11, 2023 03:30
…7-24

1. Replaced all tilde and caret characters in package.json
files with nothing so that all versions are pinned down
for safety and stability of the build/publishing process.
2. On top of just removing the tildes and carets, I also upgraded the
declared versions to whatever their caret upgrades would've been (e.g.
performed minor upgrades on all the versions). This is important because
this is how we achieve parity with the actual dependencies that were used
by the code prior to this PR - this also highlights why it is necessary to
have reproducible builds and pinned versions: because without it one has
no actual answer to the question of "So what dependencies does your code
need to function exactly?"
4. Removed the jasmine types from the root package because they
were causing build problems with the weaver tsc compilation.
The proper, longer term solution here is to make the weaver packages'
tsc configuration on-boarded to the monorepo structure, but I did not want
to blow up this commit to be 10x the current size just because of this.
I opened a couple of issues regarding this.
5. I added protobufjs as a dev dependency to the API server package because
artillery suddenly stopped working when grpcjs was upgraded and it was
complaining that one of its dependencies (protobufjs) cannot be imported.
6. I added the protocol buffer compiler to the dev container.
7. Added a new VSCode extension to the list of recommended ones because
I found it extremely useful while performing the minor upgrades in the
dozens of package.json files (100+ dependencies in total). Why? Because
all the other tooling that exists in the NodeJS ecosystem assumes that
doing major upgrades on dependencies in batch is the only thing needed.
None of the tools are able to do a minor upgrades only mass upgrade
operation, even the ones that claim this as a feature do not have it.
8. I synced the list of recommended VSCode extensions to the dev container
definition file so that the same extensions get installed automatically
in the container as well.

Fixes hyperledger-cacti#2571

Signed-off-by: Peter Somogyvari <[email protected]>
@petermetz petermetz self-assigned this Aug 11, 2023
@petermetz petermetz merged commit a8e4d55 into hyperledger-cacti:main Aug 11, 2023
108 of 119 checks passed
@petermetz petermetz deleted the petermetz/issue2571 branch August 12, 2023 01:15
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.

build(deps): pin ALL dependency versions in package.json files 2023-07-24
3 participants