fix: Refactor to prevent unnecessary lockfile changes

[monilpat]

Relates to:

#1121

Risks

• Low: The changes primarily affect the installation process and dependency management. There is a risk of potential issues if the frozen lock file is not respected, which could lead to inconsistent dependency versions across environments.

Background

What does this PR do?

This PR updates the installation commands across various files to ensure that the pnpm install command uses the --frozen-lockfile option. This prevents the lock file from being incorrectly updated during installations. Additionally, an explicit update script has been added to allow updates without the frozen lock file option. We updated the .npmrc default to set frozen-lockfile=true and in order to update the lockfile when you add a new dependency in your package.json or bump a version in your package.json you need to explicitly call pnpm i --no-frozen-lockfile

What kind of change is this?

• Improvements: This change improves the dependency management process by enforcing the use of a consistent lock file during installations.

Documentation changes needed?

• My changes require a change to the project documentation.
• If a docs change is needed: I have updated the documentation accordingly.

Testing

Where should a reviewer start?

Review the changes made in the following files to understand the impact of the updates:

• .github/workflows/pre-release.yml
• Dockerfile
• package.json
• scripts/start.sh

Detailed testing steps

• As a developer, run the installation command using pnpm install to verify that it respects the frozen lock file.
• Test the new update command by running pnpm update to ensure it updates dependencies correctly without the frozen lock file option.

[monilpat]

(integration test failure is unrelated to lockfile changes :) ) @pgoos and @jzvikart are having a look at that! This is a good first step to prevent unduly updated lockfiles :)

[jzvikart]

Hey @monilpat, I've already started working on this during weekend myself. See this branch: jure/fix-workflows-and-docs. I even went so far to try to update Chinese etc. READMEs, which is of course complete nonsense since I don't even understand what is written there. Furthermore, there are scripts that use pnpm install that I cannot really test, and since it they are undocumented it's impossible to tell if they should be changed or not.

Initially, I had a thought to update all references to pnpm install, but I changed my mind because it's not a black/white decision. People need to understand how lockfiles work, and if they are not using them properly it is not our ability (or responsibility) to educate them. The issues we're seeing today with lockfiles are the result of (1) npm / pnpm's design decision (or rather, a change of), and (2) carelesness.

The proper solution therefore boils down to PR reviewers. In particular:

• The main and develop branches should always be "stable", i.e. having passing tests
• Whenever a PR introduces a change that causes tests to fail, it should not be merged until the cause of failure is established and corrected.

That said, the tests can fail for more than lockfile being out of sync, and we should probably focus on making them work in a reliable way. One of key issues is that our tests depend on external things such as OpenAI and API keys. I would recommend adding a separate smoke test just for OpenAI (a simple curl command).

[jzvikart]

As agreed, adding frozen-lockfile=true to .npmrc is probably the best approach as it forces pnpm to use the old behaviour.