So I’m working on a boilerplate and website that relies on an Apache CouchDB database. The site boilerplate, site, and database all work pretty well, but I want to use some CI/CD tools to run testing.
I have a couple of options open to me such as using configuration management to set up the whole environment, using Docker for key pieces of the environment, or finding some libraries that mock some of my required components, like CouchDB. After looking into what I would have to learn in order to implement each of them, I ended up deciding that for the near-term just going with mocking libraries would be the easiest.
Table of Contents
Why refactor this? Where did this idea come from?
Since the site is using Redis for the cookie store, we’re using the excellent redis-mock for that. Almost entirely based on the hilarious logo for it (not actually true), we quickly decided on mock-couch to mock our CouchDB. There was one problem though: the current version of mock-couch doesn’t run with NodeJS 8.x.
So I decided to refactor it in order to bring the packages up-to-date, hopefully get it working with current versions of NodeJS, and take advantage of newer language features.
I forked it a few months ago and have been working on it on-and-off
here, under the
After I’m done I’m going to submit it back to the original author to see if he’ll
accept my PR for this.
If he doesn’t we’ll see where this goes from there.
Maybe I’ll continue development as a new package if the merge request is declined?
When I was initally trying to use this package, it always immediately threw a bunch
I was able to trace the errors back and found an open issue
that was related.
I think that it’s mostly being caused by an older version of
restify and the
spdy package that it relies on.
A subsequent commenter on that issue discovered that this problem is found only
with NodeJS > 7.x, so that means my NodeJS 8.x project is impacted.
So far, that commmenter’s pull request has not been merged in even though it’s a
fairly minor change.
Why not stop if somebody already made a Pull Request for your problem?
Because I think there are some other benefits to a deeper refactor in this case.
Case in point: the
ramda package has evolved very much since the version this
was written for and current versions of
ramda actually break this package.
Sure, that older version works, but this package also has reliance on it in ways that don’t
simplify the code, and in some cases make it more complex for developers unfamiliar
read and understand than the
This holds most true for the uses of
ramda.Compose() lets you chain a bunch of function calls together, each one putting
its outputs into the next one’s input.
Except it’s inverted.
Which isn’t intuitive at all!
You end up having to read UP the page in order to understand how the code block flows.
This might be acceptable if some very complex things were going on, but most of what
was going on could easily be solved with plain
The package as written uses
jslint, which is great.
However I kind of prefer
eslint and (in my opinion) the better tooling and
configuration that it comes with.
jslint has been replaced with
Things that I’m leaving alone… for now.
For the moment, this is using
I somewhat prefer
mocha, but I want to leave
jasmine in place at least until I’m
once again passing all tests after the refactor.
Maybe at that point I’ll replace it with
I’m also leaving
grunt in place as the task runner.
It isn’t a very complex
gruntfile at this point, so it may ultimately not be needed.
I could probably replace grunt with just
npm scripts with how simple they are.
Working on the code
Since I really wanted this to be totally up-to-date I started off by doing an
This updated all of the packages to their most current versions and this is where I
discovered the breaking changes that more modern versions of
I left everything in place as it was for the moment.
eslint --fix did a ton of work in whipping all of this code into shape.
After it’s initial pass to fix things that are pretty straightforward I then loaded
/lib into my
vim buffers and started working through the remaining
As I went along I also tried to update the broken
ramda code, but time after time
I discovered that what was going on in the
ramda calls was pretty basic stuff that
So after replacing a couple of
ramda calls with vanilla equivalents I did a quick
peak at all of the other places using
ramda and discovered that pretty much all of
them were trivial replacements, and there were only a couple of instances where I would
have to go a bit beyond “trivial” to convert things to vanilla JS.
So I came to the conclusion that
ramda wasn’t really needed and removed it from
the package dependencies.
With that out of the way I continued working through all of the buffered files, fixing
linting errors and replacing now-defunct
ramda calls with vanilla JS.
Working on the tests
eslint --fix was a lifesaver here.
It fixed a bunch of formatting issues in the tests, and the remaining ones were pretty
simple to deal with.
Mostly things like using destructuring, having individual
instead of chaining assignments with commas, implementing arrow functions for unnamed
functions, stuff like that.
Running the tests
This is where I’m at now.
It isn’t as bad as I was thinking it would be.
Roughly 50% of the tests are passing, which means that I probably just made some
goofy errors in a couple of key places as I was converting away from
I’m about to get into that now.
Once I finish up getting all of the tests to pass I’ll update with a new post, sumbit the merge request and see where this goes after that. At the very least I’ll be able to make use of it for my purposes, so definitely looking forward to that.