AlreadyExists panic/Not a directory exception while bundling

[AlexMax]

I'm attempting to bundle a React app with deno and am running into a strange backtrace if I run it with an empty cache.

alexmax@Alexs-iMac env.ts % uname -a
Darwin Alexs-iMac.local 18.7.0 Darwin Kernel Version 18.7.0: Sun Dec  1 18:59:03 PST 2019; root:xnu-4903.278.19~1/RELEASE_X86_64 x86_64
alexmax@Alexs-iMac env.ts % deno --version
deno 0.30.0
v8 8.1.108
typescript 3.7.2
alexmax@Alexs-iMac env.ts % RUST_BACKTRACE=1 deno bundle index.ts
Download https://dev.jspm.io/react
Download https://dev.jspm.io/react-dom
Download https://dev.jspm.io/npm:react@16.12.0/index.dew.js
Download https://dev.jspm.io/npm:react@16.12.0/cjs/react.development.dew.js
Download https://dev.jspm.io/npm:object-assign@4?dew
Download https://dev.jspm.io/npm:prop-types@15/checkPropTypes?dew
Download https://dev.jspm.io/npm:object-assign@4.1.1/index.dew.js
Download https://dev.jspm.io/npm:prop-types@15.7.2/checkPropTypes.dew.js
Download https://dev.jspm.io/npm:prop-types@15.7.2/lib/ReactPropTypesSecret.dew.js
Download https://dev.jspm.io/npm:react-dom@16.12.0/index.dew.js
Download https://dev.jspm.io/npm:react-dom@16.12.0/cjs/react-dom.development.dew.js
Download https://dev.jspm.io/npm:react@16?dew
Download https://dev.jspm.io/npm:scheduler@0.18?dew
Download https://dev.jspm.io/npm:scheduler@0.18/tracing?dew
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 17, kind: AlreadyExists, message: "File exists" }', src/libcore/result.rs:1165:5
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::default_hook
   5: std::panicking::rust_panic_with_hook
   6: std::panicking::continue_panic_fmt
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::result::unwrap_failed
  10: <std::future::GenFuture<T> as core::future::future::Future>::poll
  11: <std::future::GenFuture<T> as core::future::future::Future>::poll
  12: <futures_util::future::try_join_all::TryJoinAll<F> as core::future::future::Future>::poll
  13: <std::future::GenFuture<T> as core::future::future::Future>::poll
  14: futures_util::future::future::chain::Chain<Fut1,Fut2,Data>::poll
  15: <futures_util::future::future::then::Then<Fut1,Fut2,F> as core::future::future::Future>::poll
  16: <futures_util::future::try_future::map_ok::MapOk<Fut,F> as core::future::future::Future>::poll
  17: <futures_util::future::try_future::map_ok::MapOk<Fut,F> as core::future::future::Future>::poll
  18: futures_util::stream::stream::StreamExt::poll_next_unpin
  19: <deno_core::isolate::Isolate as core::future::future::Future>::poll
  20: <deno_core::es_isolate::EsIsolate as core::future::future::Future>::poll
  21: <deno::worker::Worker as core::future::future::Future>::poll
  22: <std::future::GenFuture<T> as core::future::future::Future>::poll
  23: tokio::runtime::enter::Enter::block_on
  24: tokio::runtime::context::enter
  25: deno::tokio_util::run
  26: deno::main
  27: std::rt::lang_start::{{closure}}
  28: std::panicking::try::do_call
  29: __rust_maybe_catch_panic
  30: std::rt::lang_start_internal
  31: main

If I then run the command again immediately, I don't get a Rust exception, but I get a normal pretty exception.

alexmax@Alexs-iMac env.ts % RUST_BACKTRACE=1 deno bundle index.ts
Download https://dev.jspm.io/npm:react-dom@16.12.0/cjs/react-dom.development.dew.js
Download https://dev.jspm.io/npm:react@16?dew

error: Uncaught Other: Not a directory (os error 20)
► $deno$/dispatch_json.ts:40:11
    at DenoError ($deno$/errors.ts:20:5)
    at unwrapResponse ($deno$/dispatch_json.ts:40:11)
    at sendAsync ($deno$/dispatch_json.ts:91:10)

Unfortunately, neither exception appears to give me any details as to what file path it's having issues with, or why it's having an issue with the file path in the first place.

[kevinkassimo]

This is not just happening during bundle but also during normal runs. The main problem here is that HTTP imports are cached locally using directory structure, without taking query into consideration and possibility of having file/directory of same name ... Notice that

Download https://dev.jspm.io/npm:scheduler@0.18?dew   =>  cached to dev.jspm.io/npm:scheduler@0.18
Download https://dev.jspm.io/npm:scheduler@0.18/tracing?dew   =>  cached to dev.jspm.io/npm:scheduler@0.18/tracing. However dev.jspm.io/npm:scheduler@0.18 is already a file now...

However at least I don't think we should hard-crash here. I'll do a simple patch to at least print a nicer error message.

[kevinkassimo]

Duplicate of #2790 #2763

[bartlomieju]

Fixed in #4030, pending v0.34.0 release