The task at hand
Things have changed a bit since my last blog post. The tool that was once referred to as the WebVTT JS parser has been rebranded as the WebVTT JS Validator. This is due to the fact that the tool validates the WebVTT file’s syntax according to the spec rather than create a data structure based on the WebVTT file’s contents. There are still bugs related to the JS validator. Kyle listed a bunch of bugs on his blog. There are also 32 files in either our ‘known-good’ or ‘known-bad’ test folders which could be failing due to bugs in the validator. Fixing these is my first task.
Polyfill want a cracker?
Testing bug fixes
So far, I see my bug fixing process going like this: make a WebVTT file that exhibits the bug, edit the parser code, and then check it against the WebVTT file until it works as intended. Seems simple enough. Since we already have a way of testing on the command line via Humph’s node application, I’ll use that. In order to use the tool in my tests, I needed to learn how to rebuild the Node app with my modified parser.js. I have very little experience with Node so this would take some research on my part. Thankfully, it didn’t take long to find the answers I needed.
Rebuilding the Node application
Rebuilding the Node application is a pretty straight-forward task. Since we initially used the npm (Node Package Manager) tool to install Humph’s version by typing
npm install webvtt -g
at the command line, I searched for documentation on npm and install, which I easily found.
npm can create a package from Node code in a few ways, but the easiest way is just by having a package.json file in the root of your Node app directory, navigating to said directory on the command line and then running
npm install -g
. npm will use the package.json file (which describes the Node application) to build the package and then install it. The -g option installs the package globally to be used anywhere on the command line. When I first looked at the package.json file, I was pretty confused as to what some of the properties meant. I found a very cool interactive web tool that explains what all of the options in the file do.
To semicolon or not to semicolon
This is the question: apparently, the original writer of the validator moved on to other projects. Should I fork my own version of the script and add semicolons for the sake of those developers who will come after me, or suck it up and just think to myself “When in Rome…”
So far, I haven’t come to a resolution. My priority now is to get started with bug fixing, so I’ll suck it up for now but if I have time, I’d really like to add semicolons.
Next time on the Dale in Open Source show, the bug fixing will commence!