While deploying a pretty standard feature, I was met with a build error on our NestJS e2e tests. I have no idea what went wrong and at first, I thought it was the feature that has bugs but all of the tests passed in my local machine. It forces me do roll back some changes and dig deeper.
Here is the error that I got.
expected one of "[object Object], [object Object], [object Object]", got 200 "OK"
Here is the code snippet of the e2e spec.
it('should list labels', async () => {
return request(app.getHttpServer())
.get(baseUrl)
.auth(VALID_TEST_TOKEN, { type: 'bearer' })
.expect(200)
.expect(labels);
});
Note: labels is an array of objects containing the labels.
The tests are pretty simple. Here are the versions of the packages I’m using.
- @nestjs/core –
^7.6.16 - supertest –
^6.1.13 - @types/supertest – ^
2.0.11
Based on the error message and the observations I made on other passing tests, it passes when the response is an object. When the response is an array, it complains and throws an error. The bad thing is that the error only occurred during the build process. I suspect it was the package versions.
supertest versions
After checking the latest version of supertest, I realized that they have a new version 6.1.14 released just recently. I tried to force the version to 6.1.14 in my local machine and I was able to trigger the error. It is indeed the latest version that causes issues. Why didn’t yarn2 not lock the versions in the first place?
I tried to roll it back to 6.1.13 and it worked. I decided to lock the version:
- From
^6.1.31 - To
6.1.13
This forces yarn to install the specific version. Will have to monitor supertest releases from now on as I need to catch up with the updates.
Now back to the yarn2 question: Why didn’t yarn2 lock the versions? Could it be that jenkins-x npm-test stop has its own script that is outside the control of my Dockerfile where I put yarn install --immutable?
I don’t know but that’s it for now.