Using deno_ast in a project that contains swc_common -F concurrent breaks the build

[alshdavid]

I am trying to use deno_ast in my project which also uses swc_common.

I am using it via swc_common = { version = "=0.33.18", features = ["concurrent"] }

With the concurrent feature enabled, the compiler throws:

error[E0277]: `Rc<RefCell<Vec<swc_common::errors::Diagnostic>>>` cannot be sent between threads safely
   --> /home/dalsh/.local/rust/cargo/registry/src/index.crates.io-6f17d22bba15001f/deno_ast-0.34.2/src/transpiling/mod.rs:280:46
    |
280 | impl crate::swc::common::errors::Emitter for DiagnosticCollector {
    |                                              ^^^^^^^^^^^^^^^^^^^ `Rc<RefCell<Vec<swc_common::errors::Diagnostic>>>` cannot be sent between threads safely
    |
    = help: within `DiagnosticCollector`, the trait `Send` is not implemented for `Rc<RefCell<Vec<swc_common::errors::Diagnostic>>>`
note: required because it appears within the type `DiagnosticCollector`
   --> /home/dalsh/.local/rust/cargo/registry/src/index.crates.io-6f17d22bba15001f/deno_ast-0.34.2/src/transpiling/mod.rs:266:8
    |
266 | struct DiagnosticCollector {
    |        ^^^^^^^^^^^^^^^^^^^
note: required by a bound in `swc_common::errors::Emitter`
   --> /home/dalsh/.local/rust/cargo/registry/src/index.crates.io-6f17d22bba15001f/swc_common-0.33.18/src/errors/emitter.rs:39:20
    |
39  | pub trait Emitter: crate::sync::Send {
    |                    ^^^^^^^^^^^^^^^^^ required by this bound in `Emitter` 

Is there any way around this?

[dsherret]

Is there any way around this?

No, we don't support or want to carry that maintenance burden. Generally we prefer doing concurrent stuff at a higher level than within emit and it reduces the chance of running into an swc concurrency bug.

[alshdavid]

I'm currently exploring the idea of compiling Deno (including deno_ast) to a dynamic library and consuming it within my main application using libloading.

That way the Deno dependencies can be compartmentalized within that dynamic library and the main project can remain unaffected. I haven't gotten around the issue of sharing types between the dynamic library and the main application

[dsherret]

I'm not sure about a good solution there. I'd recommend disabling swc's concurrent option. That said, DiagnosticCollector seems simple enough, so a PR that adds a Sync implementation behind a compile flag seems like an ok thing to maintain if that's the only change required in deno_ast to enable this flag (basically, I'd rather not maintain concurrent, but if it's simple and something you'd like to maintain in deno_ast then feel free to submit a PR).