loading some URLs causes a load exception

[johnspurlock]

root.ts

import dateFnsTz from 'https://cdn.skypack.dev/[email protected]?dts';
console.log(dateFnsTz);

repro.ts

import { bundle } from 'https://deno.land/x/[email protected]/mod.ts';

const root = `file:///path/to/root.ts`;
const result = await bundle(root);
console.log(result);

This worked fine under the old Deno.emit(root, { bundle: 'module' })

error: Uncaught (in promise) Error: load_transformed failed
      const ret = new Error(getStringFromWasm0(arg0, arg1));
                  ^
    at __wbg_new_3047bf4b4f02b802 (https://deno.land/x/[email protected]/lib/deno_emit.generated.js:266:19)
    at js_sys::Error::new::h99ffaa64b8859860 (https://deno.land/x/[email protected]/lib/deno_emit_bg.wasm:1:3791529)
    at <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h026cccf65c2b3db8 (https://deno.land/x/[email protected]/lib/deno_emit_bg.wasm:1:695550)
    at <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h79fa8f0207962e80 (https://deno.land/x/[email protected]/lib/deno_emit_bg.wasm:1:2651040)
    at <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::hc21402dacb8e890d (https://deno.land/x/[email protected]/lib/deno_emit_bg.wasm:1:2152909)
    at wasm_bindgen_futures::queue::Queue::new::{{closure}}::h8b5a56bdc387819e (https://deno.land/x/[email protected]/lib/deno_emit_bg.wasm:1:2055713)
    at <dyn core::ops::function::FnMut<(A,)>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::h28c77ba1afeb2b6a (https://deno.land/x/[email protected]/lib/deno_emit_bg.wasm:1:3655458)
    at __wbg_adapter_14 (https://deno.land/x/[email protected]/lib/deno_emit.generated.js:144:6)
    at real (https://deno.land/x/[email protected]/lib/deno_emit.generated.js:128:14)

[johnspurlock]

Same issue with

import { getTraversalObj } from 'https://cdn.skypack.dev/[email protected]?dts';

Perhaps all skypack urls of this form?

[johnspurlock]

Note both of these imports work fine in a standard Deno program on 1.22. ie in the repro.ts file above

[johnspurlock]

This is the biggest immediate blocker for me, as none of these valid Deno modules can be bundled at runtime on 1.22

[KnorpelSenf]

Perhaps all skypack urls of this form?

I think this may be it, I am having the same problem.

[dsherret]

Try providing an explicit url: new URL("file:///path/to/root.ts")

The error will be surfaced better once #34 lands.

[johnspurlock]

Ok, tried that (and updating to release 0.0.2), and it doesn't make a difference with any of the three projects that are failing to bundle with this module (but bundle fine with deno bundle and the old Deno.emit)

Same error, still getting load_transformed failed

[KnorpelSenf]

I am also still getting the error, but in fewer cases. I could not figure out in which cases.

I am using the API to bundle all versions of my package on /x using a script. The old Deno.emit could bundle all versions, the new one only those above 1.8.0 and with the workaround all versions above 1.7.0 work. There are no interesting changes to import statements between these tags, so I can't really tell why or how this API fails.

[wwoast]

I triaged this problem in one of my projects to an import assertion in the code I was attempting to bundle.

import testjson from "../config/test.json" assert {type: "json"}

Even a simple json file will cause the bundler to throw errors.

{
  "a": 1
}

[KnorpelSenf]

I could manually trigger the same error for any import by specifying the load option and then returning undefined (while implementing #32). I suspect that the error happens when the cache returns undefined for whatever reason, hence the generic error message that lacks details. A workaround might therefore be to manually load all files and return their string content, but this isn't optimal of course. I have yet to try this out.

[wwoast]

Quick follow-up to my earlier complaint -- tested bundling using deno_emit 0.4.0, and import assertions work perfectly now.

[yacinehmito]

This issue can be closed, as:

• import assertions work
• the original bug doesn't reproduce anymore, provided that the root is wrapped in new URL()