Let's Build a Thing: NPM Dependency Checker - Part 4
Series start along with dev notes: Let’s Build: NPM Dependency Checker
Previous part: Let’s Build: NPM Dependency Checker - Part 3
GitHub: NPM Dependency Checker
So at this point we have a “working” application and we’ve coded many core functions.
The main thing we’re missing is testing. We should have at least a few basic tests so we know our functions generally operate the way we expect. Ideally we should have many tests that thoroughly test each function, but for this series I plan on doing basic testing.
Additionally, we should probably add some brief documentation to each function. Let’s get going on this right now.
Before we get to the tests, let’s do a little bit of refactoring for the code we do have. For starters, we should put in a documentation line for each function.
To help ensure our function works as intended, let’s put a guard up. We will only use the main function when the argument being passed is a map. For all others, we will send them to a function that returns false.
We will also put in some @doc information.
We have a similar situation for the npm_view function. If we were to pass in something other than a string (binary), the function will break. Let’s add another guard along with another catch-all-else function.
For fetch_package_json we are going to modify it to raise an exception in the case of the response not being a 200 or 404.
Again we need to add a function guard.
That does it for the refactor changes for now.
With our function refactored with guarding, we can now create some simple tests.
Rather than paste out all of the tests, I will just do one. Please see the branch for this part in the repo for a full listing of tests I created.
You can run the tests by running the following in your project directory:
The test below will check that the get_package_repo_url does take the output from our npm_view function and returns the appropriate URL for the repo.
We now have documentation, tests setup and our code is a little more bulletproof. Let’s turn our attention to a major issue.
As I was testing the application, I noticed that when I ran it with –pkg=eslint the application blew up. Why? It turns out that grabbing the “homepage” key from npm view is a bad idea. In this case (and others), the homepage link is to a main site and not GitHub.
Therefore, we’re going to refactor to grab the repository.url key and work with that.
We’re going to add an attribute for pulling out the repository node in the JSON response. Put this at the top of the file with the other attribute.
Next, we need to adjust out call to npm view so that the response is in JSON. This is simply done by adding –json to our Systen.cmd call.
Next we’re going to refactor the decode_body function to take an addition argument so we can pass in the attribute we want since the function will be used in multiple places.
We need to alter the url in a different way now, so transform_repo_raw_json_url needs to be refactored. Additionally, we’re now going to pass in a List instead of a binary, so we’ll update the guard too.
The new function looks like this:
After this refactor, we’re left with a function that we no longer need (get_package_repo_url). We also need to add something to our main pipe. When the dust settles, here’s what it looks like:
After all the refactoring, we need to re-run our tests and potential add new ones.
Remove get_package_repo_url tests.
Update test for decode_body to pass the additional argument.
Update test for transform_repo_raw_json_url to pass list instead of string.
I also took out one additional test for now.
We’re at a good stopping point for this part. In the next part we’ll start working on refactoring the parse_dependencies function so that it iterates fully and we’ll begin to explore how we’re going to tackle the issue of drilling down until there are no repositories left to check.
Let’s continue forward:
Let’s Build: NPM Dependency Checker - Part 5