https://travis-ci.org/plastikfan/zenobia-ts/builds/650441521 (this build just happened)
https://travis-ci.org/plastikfan/zenobia-ts/builds/650019004 (this one a while ago)
The above 2 links are links to failed travis builds. At the time of their failure, I tried the exact same build locally and they did not report the errors that occurred on. The second build listed was actually as a result of a bad merge as a result of a conflict (I didn’t notice one of the merge conflicts in the package-lock.json; still had the >>>>> marker in it). However, when I build locally, this error didn’t break the local build. The first time I was aware of an issue is when Travis build failed. Clearly, this is not desirable.
I am currently in the process of peforming merge resolution for a different issue, and the same type of problem has cropped up again. I can’t go on like this, having local build result being different from the travis build result. What can I do to ensure that my local build will fail in the exact same way as the travis build?
I get the feeling I need to povide more info, but I’m not sure what would be relevant. My current issue is with a file being missing, but I’m not sure why I’m not seeing this locally.
Cheers.
I am assuming that travis is running some kind of pre build step that is not in my workflow that would allow errors in a package-lock.json file to go un-noticed locally that show up on travis. I have discovered that the error with the first build (a missing file) can be reproduced locally with an npm i. But this doesn’t resolve my more general issue of making sure that I can run an identical build to travis locally. Ok, so I can say, well I will just do an npm i first as a pre-publishing step, but that’s just speculating as to what Travis is going to do.