TypedArrays inconsistency between 'web' and 'no-modules'

Describe the Bug
I'm trying to write some code that takes in large Uint8Arrays and does some expensive operations on them (parsing it as a file, and then some other operations). However, this operation takes long enough (more than 10 seconds in many cases) that I want to run the web assembly in a web worker so that I don't block the main thread. If I write the code and use the web target, everything works correctly. Unfortunately, I can't use the web target if I want to use web workers, as they don't have support for modules yet. I have to use importScripts instead:
https://developer.mozilla.org/en-US/docs/Web/API/WorkerGlobalScope/importScripts
When I try to use the same code with no-modules, I get different results to web and I'm not sure why. This may not actually be a bug and I might just be doing something wrong, but it feels like it might be one (or at least the correct solution is very hard to find).
Steps to Reproduce
lib.rs (Same for both web and no-modules)
extern crate js_sys;

use js_sys::Uint8Array;
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn sanity(a: i32, b: i32) -> i32 {
    a + b
}

#[wasm_bindgen]
pub fn test_a(file_bytes: &[u8]) -> usize {
    file_bytes.len()
}

#[wasm_bindgen]
pub fn test_b(file_bytes: Vec<u8>) -> usize {
    file_bytes.len()
}

#[wasm_bindgen]
pub fn test_c(file_bytes: Uint8Array) -> u32 {
    file_bytes.byte_length()
}

index.html snippet web (works correctly)
<script type="module">
    import init, { sanity, test_a, test_b, test_c } from "./viewer.js";
    async function run() {
        await init();

        console.log(sanity(1, 2)); // Correctly prints '3'
        const bytes = new Uint8Array(12);
        console.log(test_a(bytes)); // Correctly prints '12'
        console.log(test_b(bytes)); // Correctly prints '12'
        console.log(test_c(bytes)); // Correctly prints '12'
    }
    run();
</script>

index.html snippet no-modules (does not work)
<script type="text/javascript" src="viewer.js"></script>
<script type="text/javascript">
    wasm_bindgen("viewer_bg.wasm").then((wasm) => {
        console.log(wasm.sanity(1, 2)); // Correctly prints '3'
        const bytes = new Uint8Array(12);
        console.log(wasm.test_a(bytes)); // Prints '0'
        console.log(wasm.test_b(bytes)); // Prints '0'
        console.log(wasm.test_c(bytes)); // Errors
    });
</script>

Additional Context
I added a small sanity check which just adds two numbers, and that works correctly across both attempts, so I'm fairly sure this isn't a case of me forgetting to initialize the web assembly correctly.
The error that is thrown for test_c using no-modules is TypeError: getObject(...) is undefined.

(Rather than using no-modules, you can instead use wasm-pack and then set the Webpack target to "webworker". This is a more robust solution, and it also enables you to use snippets and npm packages)

(Rather than using no-modules, you can instead use wasm-pack and then set the Webpack target to "webworker". This is a more robust solution, and it also enables you to use snippets and npm packages)

Am I able to do that without having to use something other than wasm-pack? I'd prefer not to have to download another package manager and learn how to use it just so I can get this working.
But if it's the only way in the meantime, I guess I'll just have to bite the bullet and download npm.

@peterreeves Webpack requires npm (or yarn), so you can't really avoid that.
For better or worse, the entire JavaScript community (including browser developers) use npm/yarn, it's difficult to avoid it if you want to do anything involving JavaScript.
(Of course this bug should still be fixed regardless, but I really do recommend using wasm-pack + Webpack, they solve a lot of issues when dealing with JavaScript)

Fair enough, I guess it's time I probably learnt some of this stuff anyway. Thanks for the tips on how to get it working.
I'll leave this issue open in the meantime.

Thanks for the report @peterreeves!
In this case the wasm object here resolved from the call to wasm_bindgen is actually the raw wasm module's exports, not the wrapped ones. Instead of wasm.sanity you'll want to execute wasm_bindgen.sanity, and that should do the trick!

Of course it was something small, it works perfectly now. Thanks for the quick response!