Declarations mismatch

[qt-kaneko]

sqlite3.vfs.installVfs({
  io: {
    methods: {
      //                    \/ Should be bigint as bigint is actually passed
      xRead(fid, dest, n, offset) {
        ...
      }
    }
  }
})

Not sure about these, but

// Are named without $ in declarations, but it does not work without $

let vfs = new sqlite3.capi.sqlite3_vfs();
vfs.$iVersion = ...;
vfs.$mxPathname = ...;
vfs.$zName = ...;
vfs.$szOsFile = ...;

// And

let file = new sqlite3.capi.sqlite3_file();
file.$pMethods = ...;

Also there is no capi.sqlite3_file.structInfo in declarations, would be nice to have it.

[tomayac]

Closing here as per the warning in the README, but @sgbeal FYI.

[sgbeal]

i looked at this when it was initially posted. The upstream project has nothing to do with "declarations" and type info - those are typescript-isms (or non-vanilla-JS-isms, in any case).

[tomayac]

Oh, I see that now, sorry.

So for the first point, this seems to be declared as number here:

sqlite-wasm/index.d.ts

Line 1719 in 870dca9

iOfst: number,

The second point seems to be declared here:

sqlite-wasm/index.d.ts

Lines 1652 to 1657 in 870dca9

	iVersion: number;
	szOsFile: number;
	mxPathname: number;
	pNext: WasmPointer;
	zName: WasmPointer;
	pAppData: WasmPointer;

@qt-kaneko, since you seem to have looked into this already, are you in a position to suggest fixes?

[drozycki]

@tomayac I came across this issue as well, and forked the repo with my fixes. PR here: #107

There's undoubtedly more examples of this missing $ but I couldn't find an easy way to find them all besides using all the APIs and noting where the expected behavior does not happen. Ideally the types would be generated upstream when the C types (or generated Emscripten types) are still known, but I couldn't find a way to do that either.

[drozycki]

Not to mention that the symbols without the $ would be preferable for the sake of consistency with the more-detailed C API docs.

[sgbeal]

The $ are an artifact of the C-struct-to-JS wrapper. We "need" those in JS so someone reading/writing the code (🙋‍♂️) can unambiguously ensure that they're dealing with C-struct members instead of JS object properties. Without those $ it's simply too easy to confuse C struct members with JS properties.