nsc-events-nextjs_11_141_upgrade-packages #142
Conversation
There was a problem hiding this comment.
hey @Alzavio I just saw this sorry busy with work and didn't realize I was being asked to review.
I think the main reason the CI workflow is failing is because it is set to use Node 18. The update to Node 22 requires changes to the following yml file .github/workflows/ci.yml starting on Line 18 The build and test job. You can review closed pull request #17 to see the changes there. The changed files highlights the action needed well.
Originally i was trying to use the matrix to provide more flexibility if there are different versions of Node by using a matrix example here but that was causing inconsistent issues so thought it best to just stick to one version.
My recommendation is just updating to Node 22 in the
build and test jobmentioned above then rerunning the workflow to see if it passes. Best of luck!
Thinking out loud...
Also @Alzavio when updating anywhere there is a Major version update. I would do a bit of research to see what has changed and review code where those are being used. If you recall from BC's review of semantic versioning Major changes in versioning usually indicates breaking changes. Here's a recap on semantic versioning below. I noticed when reviewing there are a few packages that had MAJOR Version (X.y.z) changes see the impact of updating those below. Here I would recommend rolling those back and reviewing the changes on each packages website to see how much of an impact it will have on the nest.js project. I'll leave some comments in the file changes for you to check out where i noticed these major version changes.
Semantic Versioning (SemVer) is a versioning system that conveys meaning about the underlying changes in a software release. It consists of three numbers separated by dots: MAJOR.MINOR.PATCH. Each number represents a different type of change in the software. Here's a breakdown of what each component generally typifies:
1. MAJOR Version (X.y.z)
- Significance: Indicates breaking changes.
- Examples:
- Removing or renaming existing features or APIs.
- Making changes that would break backward compatibility, requiring users to make changes to their code when upgrading.
- When to Increment: You increment the MAJOR version when you make incompatible API changes. This typically happens when a significant change is introduced, such as re-architecting the system, removing deprecated functionality, or making substantial improvements that affect the way the software interacts with users or other systems.
Example:
- If you change from
1.4.2to2.0.0, it means the new version is not backward-compatible with the previous one.
2. MINOR Version (x.Y.z)
- Significance: Indicates the addition of new features that are backward-compatible.
- Examples:
- Adding new functionality in a backward-compatible manner.
- Adding new APIs or methods.
- Introducing minor enhancements that don’t break existing code or user expectations.
- When to Increment: You increment the MINOR version when you add functionality in a manner that is backward-compatible. It signals to users that new features are available without requiring them to change existing code.
Example:
- If you change from
1.4.2to1.5.0, it means new features have been added, but the upgrade should be seamless.
3. PATCH Version (x.y.Z)
- Significance: Indicates backward-compatible bug fixes.
- Examples:
- Fixing bugs or issues that do not affect the API or existing functionality.
- Applying minor patches or security fixes.
- When to Increment: You increment the PATCH version when you make backward-compatible bug fixes. It’s the safest type of update, signaling that minor improvements have been made without affecting the software’s interface or behavior.
Example:
- If you change from
1.4.2to1.4.3, it means that some bugs were fixed, but there are no new features or breaking changes.
Additional Labels:
-
Pre-release Versions:
- Often used for versions that are not yet stable. They are denoted with a hyphen followed by identifiers like
-alpha,-beta,-rc.1, etc. - Example:
1.0.0-alpha,2.0.0-beta,1.0.0-rc.1.
- Often used for versions that are not yet stable. They are denoted with a hyphen followed by identifiers like
-
Build Metadata:
- Information that does not impact version precedence, denoted by a
+sign. - Example:
1.0.0+001,1.0.0-beta+exp.sha.5114f85.
- Information that does not impact version precedence, denoted by a
Summary:
- MAJOR (X): Breaking changes; increment when backward compatibility is broken.
- MINOR (Y): New features; increment when adding new, backward-compatible functionality.
- PATCH (Z): Bug fixes; increment when making backward-compatible bug fixes.
Semantic versioning helps users and developers understand the impact of upgrading to a new version of the software, ensuring that version numbers convey meaningful information about the nature of the changes introduced.
@bcko Hope this helps :)
| "date-fns": "^3.6.0", | ||
| "mongoose": "^7.4.2", | ||
| "passport": "^0.6.0", | ||
| "mongoose": "^8.5.3", |
There was a problem hiding this comment.
Major version update. May be best not to include this until you can identify the breaking changes being introduced. See Semantic Versioning breakdown in main comment.
| "@types/passport-jwt": "^4.0.1", | ||
| "@types/passport-local": "^1.0.38", | ||
| "@types/supertest": "^6.0.2", | ||
| "@typescript-eslint/eslint-plugin": "^8.1.0", |
There was a problem hiding this comment.
Major version update. May be best not to include this until you can identify the breaking changes being introduced. See Semantic Versioning breakdown in main comment.
| "@typescript-eslint/eslint-plugin": "^8.1.0", | ||
| "@typescript-eslint/parser": "^8.1.0", | ||
| "eslint": "^9.9.0", | ||
| "eslint-config-prettier": "^9.1.0", |
There was a problem hiding this comment.
Major version update. May be best not to include this until you can identify the breaking changes being introduced. See Semantic Versioning breakdown in main comment.
| "@typescript-eslint/parser": "^8.1.0", | ||
| "eslint": "^9.9.0", | ||
| "eslint-config-prettier": "^9.1.0", | ||
| "eslint-plugin-prettier": "^5.2.1", |
There was a problem hiding this comment.
Major version update. May be best not to include this until you can identify the breaking changes being introduced. See Semantic Versioning breakdown in main comment.
| "eslint-config-prettier": "^9.1.0", | ||
| "eslint-plugin-prettier": "^5.2.1", | ||
| "jest": "^29.7.0", | ||
| "prettier": "3.3.3", |
There was a problem hiding this comment.
Major version update. May be best not to include this until you can identify the breaking changes being introduced. See Semantic Versioning breakdown in main comment.
| "ts-jest": "^29.1.0", | ||
| "ts-loader": "^9.4.3", | ||
| "ts-node": "^10.9.1", | ||
| "supertest": "^7.0.0", |
There was a problem hiding this comment.
Major version update. May be best not to include this until you can identify the breaking changes being introduced. See Semantic Versioning breakdown in main comment.
| "@types/express": "^4.17.21", | ||
| "@types/jest": "^29.5.12", | ||
| "@types/node": "^22.3.0", | ||
| "@types/passport-jwt": "^4.0.1", |
There was a problem hiding this comment.
Major version update. May be best not to include this until you can identify the breaking changes being introduced. See Semantic Versioning breakdown in main comment. I believe this is for our auth. So may be required if there are vulnerabilities in the old package and may be a priority to look into first.
| "@types/bcryptjs": "^2.4.6", | ||
| "@types/express": "^4.17.21", | ||
| "@types/jest": "^29.5.12", | ||
| "@types/node": "^22.3.0", |
There was a problem hiding this comment.
Major version update. May be best not to include this until you can identify the breaking changes being introduced. See Semantic Versioning breakdown in main comment.
There was a problem hiding this comment.
If this is being deleted. In the yml file mentioned in the main comment you may need to run npm i rather than npm ci.
|
Closing PR for now, will request more developers to trouble shoot in next sprint. Package updates will become part of our sprint cycles. |
Resolves 141, upgrading the packages in the repo. Including Node to 18 -> 22
Key Learnings: Had to learn how nestjs works to test this out properly (also needed to do this for a review for this project), and how we're using mongoose/mongodb with it.