0

At work we're using a very old template (generated around April 2021, so node v14.19) which has an out of sync package-lock.json. This means that if you do:

rm package-lock.json && npm install

The install will fail due to conflicting dependencies.

For a couple of weeks me and my teammates tried to fix this, but we haven't succeed yet: when you fix the dependencies you break eslint, when you fix eslint you break deployment, when you fix deployment then the logger will stop working and so on. We have thousands of dependencies that are turning out to be an hell to maintain.

The pov of our CTO is that we simply shouldn't delete the package-lock.json, but this means we can't update node and we are stick with what I think is a huge technical risk.

  • Do you think it's fixable? Have you ever been in a similar situation?

  • Is not deleting the package-lock.json enough to avoid the problem?

  • If not, how could I produce an example where I can break the flow? maybe by installing a modern package that is incompatible with the old resolution?

Mascarpone
  • 2,516
  • 4
  • 25
  • 46
  • not updating packages is a huge security risk as new security CVEs are discovered daily and are exploited by people with malicious intent. Your CTO should read up on the risks with outdated third party dependencies and the longer you postpone updating the higher the risks are and the more expensive its going to be in the long run. – Toerktumlare Jan 28 '23 at 13:09
  • thanks @Toerktumlare but unfortunately he's not sensible to this topic :( I feel I need to prove that we will break our development flow to convince him. – Mascarpone Jan 28 '23 at 13:12
  • you asked what the risks where, and i answered – Toerktumlare Jan 28 '23 at 13:14
  • to be honest @Toerktumlare we can update dependencies and remove CVEs, what we can't do is update node or remove the `package-lock.json` – Mascarpone Jan 28 '23 at 13:23

1 Answers1

0

This is one of the reasons why both modular code and teams are important. Chunking the code up to one big file or just a few files will cause this kind of mess.

Do you think it's fixable? Have you ever been in a similar situation?

Yes

Is not deleting the package-lock.json enough to avoid the problem?

No. As said in the comments, it is a big security risk not to keep your dependencies up to date. That's why you have package managers like npm. Plus, new vulnerabilities are openly discussed in different forums, so not only are scrupulous elements aware of them, good intentioned programmers are aware of them and will definitely judge your software to be of low quality. Also, you put your clients at a big risk of running into trouble with your software and put your company at risk of facing litigations.

If not, how could I produce an example where I can break the flow? maybe by installing a modern package that is incompatible with the old resolution?

My Suggested Solution:

  1. Leave the code as is (Good thing it is still working even with new input data).
  2. Modularize the code. Put chunks of related functionalities into separate files and import them into the main code (make sure everything is still working).
  3. Assign teams to the seperate files (modules) to build new versions of the code (there also have to be modular testing implemented here so you can test each module independent of the main file).
  4. For each test unit, make sure they have their own up-to-date package.json file.
  5. Integrate everything into a new project software.

One advantage of doing things this way is that the main file code rarely changes. Also, each module can be updated independent of the main program and other modules. Only downside to this approach is that you have to manage the package.json file intentionally so that dependecies do not conflict or are not recursive during integration, thereby (sometimes) requiring a seperate team to manage integration.

Udo E.
  • 2,665
  • 2
  • 21
  • 33