build: FORMS-1702 frontend nanoid vulnerability fix

[WalterMoar]

Description

The GitHub Dependabot process has created an alert for the nanoid dependency. To satisfy the requirements outlined in the Security Threat and Risk Assessment's (STRA) Statement of Acceptable Risks (SoAR), this vulnerability must be handled by updating the package version (or mitigated in some other way, if updating the package is not possible).
https://github.com/bcgov/common-hosted-form-service/security/dependabot/220

Acceptance Criteria

• The vulnerability no longer appears in the dependabot list

Type of Change

build (change in build system or dependencies)

Checklist

• I have read the CONTRIBUTING doc
• I have checked that unit tests pass locally with my changes
• I have run the npm script lint on the frontend and backend
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• I have approval from the product owner for the contribution in this pull request

[abhilash-aot]

To address security vulnerabilities in nested package versions, instead of manually modifying the package-lock.json, we can use the overrides property in package.json. This approach allows us to regenerate package-lock.json later, ensuring consistency across package dependencies. It also handles scenarios where a new package is added or when multiple packages depend on the same nested package at varying versions. By using overrides, we gain better visibility and control over what has been updated.

For more details, refer to the npm documentation on overrides

[WalterMoar]

To address security vulnerabilities in nested package versions, instead of manually modifying the package-lock.json, we can use the overrides property in package.json. This approach allows us to regenerate package-lock.json later, ensuring consistency across package dependencies. It also handles scenarios where a new package is added or when multiple packages depend on the same nested package at varying versions. By using overrides, we gain better visibility and control over what has been updated.

For more details, refer to the npm documentation on overrides

The overrides are a great tool if the packages are restricted to vulnerable versions. However, that's not the case here - I should have included the full details in the Jira task, but here they are now:

• We depend on vite
• vite depends on postcss
• postcss depends on nanoid with version ^3.3.7
• The nanoid version in our package-lock.json was v3.3.7
• The fixed nanoid version is v3.3.8

If the postcss dependency was strictly 3.3.7 then yes, the override would be a great way to force v3.3.8 and sort-of-document the update to package-lock.json. But since the dependency is ^3.3.7 and 3.3.8 is a valid version for that dependency, then I just wanted that one dependency on nanoid updated, so I did npm update nanoid. I didn't want to do npm update postcss because that's going to update both postcss and nanoid. Similarly I didn't want to do npm update vite because then it updates all kinds of dependencies. So I chose to just update nanoid to try to keep the risk of this change as low as possible.

In other words, if we were to completely rebuild the package-lock.json using the package.json as it is, then we'd get nanoid v3.3.8 without any override needed.