[Snyk] Upgrade tslib from 2.4.0 to 2.8.1

[nejidevelops]

Snyk has created this PR to upgrade tslib from 2.4.0 to 2.8.1.

ℹ️ Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

---

• The recommended version is 12 versions ahead of your current version.

• The recommended version was released 7 months ago.

Release notes

Package name: tslib

• 2.8.1 - 2024-10-31
  

  What's Changed

  • Fix publish workflow by @ andrewbranch in #271
  • Include non-enumerable keys in __importStar helper by @ rbuckton in #272
  • Remove use of ES2015 syntax by @ andrewbranch in #275

  Full Changelog: v2.8.0...v2.8.1

• 2.8.0 - 2024-10-15
  

  What's Changed

  • Validate export structure of every entrypoint by @ andrewbranch in #269
  • Add rewriteRelativeImportExtension helper by @ andrewbranch in #270

  Full Changelog: v2.7.0...v2.8.0

• 2.7.0 - 2024-08-23
  

  What's Changed

  • Implement deterministic collapse of await in await using by @ rbuckton in #262
  • Use global 'Iterator.prototype' for downlevel generators by @ rbuckton in #267

  Full Changelog: v2.6.3...v2.7.0

• 2.6.3 - 2024-06-04
  

  What's Changed

  • 'await using' normative changes by @ rbuckton in #258

  Full Changelog: v2.6.2...v2.6.3

• 2.6.2 - 2023-08-18
  

  What's Changed

  • Fix path to exports["module"]["types"] by @ andrewbranch in #217

  Full Changelog: v2.6.1...v2.6.2

• 2.6.1 - 2023-07-24
  

  What's Changed

  • Allow functions as values in __addDisposableResource by @ rbuckton in #215
  • Stop using es6 syntax in the es6 file by @ andrewbranch in #216

  Full Changelog: 2.6.0...v2.6.1

• 2.6.0 - 2023-06-26
  

  What's Changed

  • Add helpers for using and await using by @ rbuckton in #213

  Full Changelog: v2.5.3...2.6.0

• 2.5.3 - 2023-06-02
  

  What's Changed

  • Do not reference tslib.es6.js from package.json exports by @ andrewbranch in #208

  Full Changelog: 2.5.2...v2.5.3

• 2.5.2 - 2023-05-18
  

  This release explicitly re-exports helpers to work around TypeScript's incomplete symbol resolution for tslib.

• 2.5.1 - 2023-05-17
  

  This release of tslib provides fixes for two issues.

  First, it reverses the order of init hooks provided by decorators to correctly reflect proposed behavior.

  Second, it corrects the exports field of tslib's package.json and provides accurate declaration files so that it may be consumed under the node16 and bundler settings for moduleResolution.

• 2.5.0 - 2023-01-26
• 2.4.1 - 2022-10-31
• 2.4.0 - 2022-04-22

from tslib GitHub release notes

---

Important

• Check the changes in this PR to ensure they won't cause issues with your project.
• This PR was automatically created by Snyk using the credentials of a real user.

---

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.

For more information:

• 🧐 View latest project report
• 📜 Customise PR templates
• 🛠 Adjust upgrade PR settings
• 🔕 Ignore this dependency or unsubscribe from future upgrade PRs

[gemini-code-assist]

Hello @nejidevelops, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

Summary of Changes

Hello team, Gemini here with a summary of this pull request. This PR was automatically generated by Snyk to upgrade the tslib dependency in the @iote/bricks-angular package. The goal is to update tslib from version 2.4.0 to 2.8.1 to incorporate the latest fixes and features from the library, as recommended by Snyk for keeping dependencies up-to-date.

Highlights

• Dependency Upgrade: The primary change is the upgrade of the tslib dependency from version 2.4.0 to 2.8.1.
• Lockfile Updates: The package-lock.json file has been updated to reflect the new tslib version and its integrity hash. Additionally, the lockfile includes updates and additions for several other dependencies and peer dependencies, including various @angular/* packages, @firebase/* packages, lodash, moment, rxjs, subsink, and zone.js, likely resolved as part of the dependency update process.
• Package Version Bump: The version of the @iote/bricks-angular package itself has been incremented from 2.0.0 to 2.0.5 in the lockfile.

Changelog

• libs/util/iote/bricks-angular/package-lock.json
  • Updated the package version of @iote/bricks-angular from 2.0.0 to 2.0.5 (line 3, 9).
  • Updated the resolved version of tslib from 2.4.0 to 2.8.1 and its integrity hash (line 287-290, 454-457).
  • Updated the required version range for tslib in the root package dependencies from ^2.3.0 to ^2.8.1 (line 11).
  • Added/updated numerous entries in the packages and dependencies sections for @angular/*, @firebase/*, @iote/time, lodash, moment, parse5, rxjs, subsink, and zone.js, reflecting their resolved versions and dependencies (lines 17-28, 30-71, 74-460).
• libs/util/iote/bricks-angular/package.json
  • Updated the tslib dependency version range from ^2.3.0 to ^2.8.1 (line 24).

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

---

Dependency needs bump,
Snyk bot makes the jump,
Lockfile grows wide,
New versions inside,
No more old code lump.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This PR, initiated by Snyk, aims to upgrade tslib from version 2.4.0 to 2.8.1. The tslib dependency itself is correctly updated to ^2.8.1 in package.json and resolved to 2.8.1 in package-lock.json.

However, the changes in package-lock.json indicate a much broader set of updates than just tslib. Specifically:

1. The version of the @iote/bricks-angular package itself is reflected as 2.0.5 in the lock file, changing from 2.0.0 as per the diff.
2. The peerDependencies for @iote/bricks-angular (as recorded in the lock file's root package entry) have been substantially expanded and updated.
3. Consequently, numerous other Angular and related dependencies (e.g., @angular/common, @angular/core, etc.) show version updates in the package-lock.json, generally moving from 14.0.x versions to 14.2.x or 14.3.x.

These broader changes likely stem from the state of the package.json file on the target branch before Snyk applied its tslib update. Snyk's action of updating tslib in package.json and then regenerating the package-lock.json would naturally incorporate these existing modifications from the package.json into the lock file.

While Snyk's direct modification to package.json (as per the provided diff) is limited to tslib, the resulting PR and its package-lock.json will merge all these changes. It's crucial that the team is aware of, has validated, and has tested this full scope of updates, not just the tslib bump. The PR title and description might need to be updated to reflect the full impact of the changes being introduced through the package-lock.json.

Summary of Findings

• Misleading PR Scope: Package Version Bump: The package-lock.json shows that the @iote/bricks-angular package version is changing from 2.0.0 to 2.0.5. This is not mentioned in the PR title or description, which focuses solely on tslib.
• Misleading PR Scope: Peer Dependency Changes: The peerDependencies for @iote/bricks-angular (reflected in package-lock.json) have been significantly expanded and updated. This broadens the PR's impact considerably beyond a simple tslib upgrade.
• Consequential Dependency Updates: As a result of the (likely pre-existing) changes in package.json's version and peer dependencies, many other Angular and related packages have been updated to newer versions in the package-lock.json.
• Need for Comprehensive Testing: Given the scope of changes reflected in the package-lock.json (package version, peer dependencies, and numerous transitive dependency updates), thorough testing is essential to ensure no regressions or unexpected behavior.

Merge Readiness

This pull request, while initiated for a tslib upgrade, results in a package-lock.json that reflects a broader set of changes, including a version bump for the @iote/bricks-angular package itself (from 2.0.0 to 2.0.5) and significant updates to its peerDependencies. These changes, in turn, lead to updates in many other Angular-related dependencies.

Due to the expanded scope of these changes beyond the tslib update, I recommend that these modifications be carefully reviewed and validated by the team to ensure they are intended and align with current development efforts. The PR title and description should ideally be updated to reflect the full extent of the changes being introduced by the package-lock.json update.

Given the high severity concerns regarding the clarity of the PR's scope and its potential impact, I recommend that these points be addressed before merging. As an AI, I am not authorized to approve pull requests; this decision rests with the designated reviewers after considering the full context.

[gemini-code-assist]

The package-lock.json indicates that the version of the main package @iote/bricks-angular is changing from 2.0.0 to 2.0.5.

This is a significant change beyond the tslib upgrade mentioned in the PR title. Could you clarify if this package version bump is an intended part of this PR's scope, or if the package.json on the target branch was already updated to 2.0.5 prior to Snyk's tslib modification?

Understanding the origin of this version change is important for assessing the PR's overall impact.

[gemini-code-assist]

Similar to the root version field, the version within the packages[""] entry also reflects the change from 2.0.0 to 2.0.5 for @iote/bricks-angular. This reinforces that the PR effectively upgrades the package version.

[gemini-code-assist]

The peerDependencies for @iote/bricks-angular, as recorded in this lock file's root package entry (packages[""]), have undergone substantial changes. This includes:

• New additions like @angular/cdk: ^14.2.0, @angular/flex-layout: ^14.0.0-beta.40, @angular/forms: ^14.2.0, @angular/material: ^14.2.0, @angular/router: ^14.2.0, @iote/time: ^2.0.0, lodash: ^4.17.21, rxjs: ^7.4.0, and subsink: ^1.0.2.
• Version updates for existing peer dependencies like @angular/common (to ^14.2.0) and @angular/core (to ^14.2.0).

These changes imply that the package.json file on the branch Snyk is targeting already contains these updated peerDependencies. While the PR is titled as a tslib upgrade, these modifications to peer dependencies (and their subsequent resolution in the lock file) represent a significant expansion of the project's dependency surface and potential impact. It's important to ensure these changes are intended and thoroughly tested.