This worked without issue in 1.4.6:
deno bundle src/main.ts $DENO_INSTALL_ROOT/bin/example.bundle.js
Now, I am getting this error:
Bundle file:///redacted/path/to/src/main.ts
Check file:///redacted/path/to/src/main.ts
thread 'main' panicked at 'not implemented: namespaced re-export: local=path#42, all=true', /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/swc_bundler-0.12.0/src/bundler/chunk/export.rs:219:29
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
@kitsonk I see you added the "needs info" label. Can I help by providing any specific info (sanitized of details about my code/computer)?
This looks like an upstream SWC issue. @kdy1 has mid term exams right now, so let's wait with pinging him about it for a few more days :-)
@jsejcksn providing source code would be very helpful anyway
Hi @bartlomieju. Unfortunately, I'm not able to share any source code from this repository... it is a private project.
Can you please try to reduce it into something reproducible? Or please provide the output of deno bundle -L debug sanitized, otherwise we are just guessing at what is causing the issue. It maybe an swc issue, it maybe that we need to do something before handing it over to swc. Without a minimal reproduction it is just guessing...
@kitsonk I don't think that is necessary. @jsejcksn has just run into a unimplemented! in swc: https://github.com/swc-project/swc/blob/master/bundler/src/bundler/chunk/export.rs#L219.
@lucacasonato we have 15 test cases having to do with bundling (and likely found another half dozen which we didn't write up) that ensure defects we encountered in swc are legitimate and valid... Just because something isn't implemented in swc doesn't mean it is valid, and a minimal reproduction would a) allow swc to fix the issue and b) give everyone a test case to make sure it doesn't happen again.
I have something similar issue:
RUST_BACKTRACE=1 deno bundle -c tsconfig.json src/egonet.ts egonet.bundle.js
thread 'main' panicked at 'cannot access a scoped thread local variable without calling `set` first', /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped-tls-1.0.0/src/lib.rs:168:9
stack backtrace:
0: std::panicking::begin_panic
1: swc_ecma_transforms::proposals::decorators::legacy::Legacy::handle::{{closure}}
2: swc_ecma_transforms::proposals::decorators::legacy::Legacy::handle
3: <swc_ecma_transforms::proposals::decorators::legacy::Legacy as swc_ecma_visit::Fold>::fold_decl
4: swc_ecma_visit::Fold::fold_stmt
5: <swc_ecma_transforms::proposals::decorators::legacy::Legacy as swc_ecma_visit::Fold>::fold_module
6: swc_bundler::bundler::load::<impl swc_bundler::bundler::Bundler<L,R>>::load_transformed
7: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::next
8: deno::bundle_command::{{closure}}
9: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
10: tokio::runtime::Runtime::block_on
11: deno::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Perhaps related to the use of decorators in my code. Easily reproducible by cloning my repo and issue the deno bundle command above.
@jveres can you also try deno run --no-check and see if the error still happens as well while we investigate.
thanks @kitsonk - yep, I did try that but the same exception occurs.
This is a bug of swc_bundler. I'll fix it soon.
@kitsonk I would very much like to help in solving this, but I'm not sure how to do that in regard to your request: I'm not able to provide any specifics about the project (even fs metadata) due to NDA, and it looks like the debug logs contain references to specific file names, function names, etc. Not sure about how to go about creating a minimal repro case because the project is rather large (lots of cross-referenced module files and megabytes of source). If there's a way to help that doesn't relate to this specific repository, please let me know. I can say for sure that I am able to bundle successfully again simply by using Deno version 1.4.6.
Can anybody help me with writing a test for it?
I wrote some tests about namespace reexport, but it passes.
@kdy1 here's a failing test:
// bar.ts
export default {
"hello": "world",
}
// foo1.ts
export * as bar from "./bar.ts";
export const d = "d1";
export default {
"a": "a1",
"b": "b1",
"c": "c1",
}
// foo.ts
export * as bar from "./bar.ts";
export const d = "d";
export default {
"a": "a",
"b": "b",
"c": "c",
}
// main.ts
import foo from "./foo.ts";
import foo1 from "./foo1.ts";
console.log(foo);
console.log(foo1);
▶ target/debug/deno bundle ./main.ts bar.bundle.js
Bundle file:///Users/biwanczuk/dev/deno/main.ts
Check file:///Users/biwanczuk/dev/deno/main.ts
thread 'main' panicked at 'not implemented: namespaced re-export: local=bar#4, all=true', /Users/biwanczuk/.cargo/registry/src/github.com-1ecc6299db9ec823/swc_bundler-0.12.0/src/bundler/chunk/export.rs:219:29
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Thanks @kdy1!
Most helpful comment
This looks like an upstream SWC issue.
@kdy1has mid term exams right now, so let's wait with pinging him about it for a few more days :-)