@chgl thanks for this work here. Upon review, we noted a few items:

• This PR re-introduces the package-lock.json which we had excluded previously. When doing an npm install, it would re-generate the package-lock.json and make it look like it changed and it would cause problems if installing on Mac/Windows. Let me find any related issues for this particular problem.
• We (me) want to take a look at some previous issues to see if express is being used here.

If you could also resolve the conflicts on your branch, that would be helpful for our review. Thank you!

Thanks for the feedback! I believe the first issue is a result of using unpinned dependencies with npm install, which will install the most recent version of a package within the semver range specified in package.json and update the lock file as a result. Using npm Clean-Install (https://docs.npmjs.com/cli/v9/commands/npm-ci) should use only the lock file and avoid needless changes to it. If there are issues with this on some plarforms, then it might be more convenient not to use the lock file of course. I'd still recommend pinning the dependencies.

I'll go ahead and rebate and resolve the conflicts later this week.

After discussion with the Atlas/WebAPI WG, we'd like to move this forward but with a change in direction. We agree that using a fixed version for each dependency in package.json makes sense and we support that change. However, we do not want to include the package-lock.json in the repository as this file is not necessary and usually leads to confusion as it can vary between developers, operating systems, etc. We had encountered this issue with package.lock previously (I can find the issue if needed) so if you can put package-lock.json back into the .gitignore than these changes will work. Thank you!

Sure, I stumbled upon a strange esprima parse error with some version which I'll have to resolve first, but other than that I'm still on it. I agree that diverging package lock isn't ideal but it should be avoidable when using npm ci (https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable). I believe the initial error from #1157 (2018) may not actually be relevant nowadays anymore. I'll go ahead and test it on windows and in a Linux Container an report back to be sure. I'm ok with refactoring this PR to stick to pinning dependency versions and keep git-ignoring the lock file.

Note that the use of a lock file is generally recommended by the ossf as well, should we eventually decide to adopt one in a future pr if no issues remain; https://github.com/ossf/package-manager-best-practices/blob/main/published/npm.md#use-a-lockfile

Thanks @chgl - this is really helpful information regarding npm! Appreciate you sharing it and also for refactoring this PR to stick to pinning dependency versions and keep git-ignoring the lock file.

I've re-added package-lock.json to gitignore, I've split dependency-pinning and updates in two commits for better visibility - the major updates only affect dev dependencies, the other should be the actual versions installed as a result of the semver constraint anyways so there shouldn't be any regression (hopefully).

Just for completeness: I couldn't reproduce the issue from #1157 or detected any unexpected changes to the package-lock file when installing using npm clean-install - on either windows or linux.

Edit: I've not removed the express dependency in case there is any doubt, but I didn't see it being used anywhere.

@anton-abushkevich sorry about that! And thanks for double-checking! I've tested it locally and could reproduce the issue. I've now updated all libraries to the latest version accepted by the former semver range.

Thanks @chgl could you merge master into your feature branch to resolve the conflicts here? Thanks!