dfinity / node-motoko

Compile and run Motoko smart contracts in Node.js or the browser.
Apache License 2.0
15 stars 4 forks source link

Subsequent compilations of the same code result in different wasm #25

Open infu opened 1 year ago

infu commented 1 year ago

Hey, great work. I am already adding it to the Blast playground. One thing is holding me back on an awesome feature. When I subsequently compile the same code I get a different wasm and a different hash

image

When I reload the page, I get the same 3 hashes. Which probably means something needs to be reset before every compilation.

infu commented 1 year ago
describe('deterministic', () => {
    test('results in the same module_hash', () => {
        const path = 'test__check__.mo';
        mo.write(path, actor);
        expect(mo.check(path)).toStrictEqual([]);

        const compile = (code : any) => {
            let f = mo.file("IC.mo")
            f.write(code)
            return f.wasm("ic");
        }

        let a = compile(actor);
        let b = compile(actor);
        expect(a.wasm).toEqual(b.wasm);

    });
});
infu commented 1 year ago

It will also be great if we have the version names instead of "latest" and older version never change. This will allow us to verify canister module_hash. Something like this will probably solve the issue above

export const createMotoko = (ver : string) => {
    return require('../../versions/' + ver + '/moc.min').then((pkg: any) => {
        return wrapMotoko(pkg, ver);
    })
}
infu commented 1 year ago

I got it running on my end, but it's slow, buggy and ugly hack :)

image
rvanasa commented 1 year ago

Glad you found a temporary solution. Since we've only been using node-motoko for internal projects until this point, I'll look into adding more flexibility around versioning (especially once we stabilize the JS bindings).

@chenyan-dfinity, do you have any suspicions around what could be causing the wasm to change for each compilation (given that node-motoko is wrapping moc.js)?

chenyan-dfinity commented 1 year ago

I think it's due to the counter in generating unique type names. These type names get propagated to Wasm as error messages, name section and custom sections, etc. If we have a way to reset the counter, it should be deterministic.