Making updates to citibank-statement-to-sheets

For months now I have been using my app to import Citibank statements into Google sheets without any issues. This weekend, however, I imported my latest statement and opened the sheet to discover something had went wrong and the import had put values into the wrong cells.  “This should be pretty straightforward to fix” I thought. “I just need to add a test for this case.” Of course it wasn’t quite as simple as I hoped.

Updating to TypeScript version 2

I opened Visual Studio Code and the first thing I saw was the message

Version mismatch! global tsc (1.8.10) != VS Code's language service (2.2.1). Inconsistent compile errors might occur.

While only a warning, this did prompt me to update the version of TypeScript used in the project and also to question whether I needed to have it installed globally.

Since the application is compiled with webpack and I don’t run the tsc command directly anymore I didn’t see a reason to have it installed globally, however the official docs always seem to provide the install command with the global flag, so I was unsure if it would work. I did uninstall it globally and had no issues from doing so.

With TypeScript only installed locally I then updated it by uninstalling it locally, increasing the version in my package.json file to the latest version and then running npm install again. As part of the upgrade in my tsconfig.json I changed the target from “es6” to “es2015”. It did appear to work as “es6”, but according the documentation that is not a supported value.

Migrating from typings to @types

Now that I was using TypeScript version 2, I could add definition files directly from npm. I uninstalled the typings package and removed it from my package.json. I also deleted the typings.json file and all the typings I had imported with typings. Then I installed the definition files through npm like so “npm install @types/pdf --save-dev”.

After doing this I was getting TypeScript compile errors when building the app where it was complaining that it could not find types that were in the newly imported definition files e.g.

ERROR in ./src/PdfScraping/PdfScraper.ts
(34,38): error TS2304: Cannot find name 'PDFDocumentProxy'.

A hunch told me that I probably needed to update ts-loader and a google search found this StackOverflow question that confirmed it. Updating fixed the error and the application was compiling once again.

I did find that VS Code works better with the latest TypeScript version and @types. Before it wouldn’t always find definitions and would then incorrectly display errors in the UI, but I haven’t had that happen since updating. I did need to close and reopen VS Code though to get it to pick up new definition files as I added them.

Sidetracked by a Chrome behaviour change

After getting the application compiling again, I ran the tests to check that everything still behaved correctly. They failed!

This stumped me for a long time. The output I was getting from karma contained

Chrome 56.0.2924 (Windows 10 0.0.0): Executed 0 of 0 ERROR (0.002 secs / 0 secs)

which showed that it wasn’t picking up the tests. Because I had not run the tests before making any changes I thought that it was something I had changed that was causing this. It was a while before I noticed this message in the console in Chrome when running the tests

Refused to execute script from 'http://localhost:3334/base/src/Statements/Parsing/StatementParserTests.ts' because its MIME type ('video/mp2t') is not executable.

This appears to be a change in Chrome’s behaviour and jtson provided a fix in this Github issue. Adding

mime: {
 "text/x-typescript": ["ts"]

into karma.conf.js fixed the issue. This was not the last frustrating problem I encountered.

Could not test locally

I also had issues setting up localhost as an authorised JavaScript origin in the Google Developer Console for the application. This was annoying as it prevented me from running the application locally to test. I attempted to get it to work for a while, but in the end gave up and decided to release it and test it live, hoping that the updates didn’t cause any issues.

Unfortunately those plans never work out and the application is currently broken with a script error. I will have to work out how to get localhost working again so that I can test and fix the issue locally.

Update: A day later

Well, it turns out I simply didn’t wait long enough for the new authorised origin to be accepted. I tried setting it again, waited a bit longer and then tried out testing locally and it worked. I then also tried the application out again and it worked too. Following that I tested out the deployed version and it also worked!

I’m not sure what happened, maybe it was tiredness (it was late at night) causing me to not pay enough attention. Oh well, the upside is it is working and I don’t need to make any further changes. I will have to keep an eye out and see if it plays up again.

Making updates to citibank-statement-to-sheets