May I ask what exactly is your use case for sql.js on node.js ? sql.js is slower, more limited, and uses more memory than a native sqlite. If you are working on both node and the browser, I would suggest writing a small abstraction layer that can talk to eithernative SQLite or sql.js depending on the platform. There isn't really any point in running sql.js on node.

I have a project running nodejs on different processor and operating system, including MIPS and x86, so making code portable might be helpful for this.
Currently the tests passed on debug mode.

SQLite is an extremely portable piece of software. It should work without issue on almost any architecture. Especially if you plan to run on less powerful hardware, I would encourage you to use a native solution.

The code works good without Closure Compiler, but I have no idea how Closure Compiler breaks it.

Compressingsql-asm-debug.js withuglify-js -m option result a 2,493kb file and all tests passed.

Please consider this change again! One benefit of this capability is that if you're on a shared host your host can upgrade the underlying NodeJS version without you having to recompile SQLite bindings. Right now I need to re-build my SQLite packages when NearlyFreeSpeech.NET moves to the next NodeJS LTS version. If I'm not on my toes, my site could be down for some time (obviously, this is not mission critical for me, but could be for others).