Last year I created a small “learn-typing”-project to learn ReactJS. Looking back let’s see how the “legacy” code holds up and let’s clean up a couple of things to make the code more readable in the future.
The first thing to take a look at is the package.json. One thing that I did not take particular care of was how I installed packages. I simply used ‘npm i <package>’ and called it a day.
However you should differentiate:
- ‘dependencies’, modules used during runtime
- ‘devDependencies’, modules used during development.
To clean things up I moved all @types packages, react-scripts and typescript to the correct ‘devDependencies’.
Now that everything is organized we can look if further actions are needed.
It is important to keep the dependencies in production up to date. The major concern is to fix security vulnerabilities. We can run the command:
npm audit fix --only=prod
This will upgrade the packages and apply the available patches for the issues.
We can also update all packages to the newest package version. This however may come at the cost that code needs to be adjusted to work with the new version of the packages.
My approach is updating single packages and then see if everything still works as expected, and then update the next package.
Now the last thing, (or actually the first thing) we need to check are the licenses used by our project and if we can use the modules in production.
With the NPM tool ‘license-checker‘ we can quickly analyse our packages.
npm i -g license-checker
license-checker --onlyunknown --production
Takes a look at all packages used during production that do not have a standard licence.
To figure out what is going on you now must go to the specific package and read up on what the exact license is. There are now two approaches: you get a legal team to figure out how this modification will affect your product, or you try to replace this dependency with an alternative.
In the next step of the refactoring I will take a look at how I can replace this dependency with a custom package.