At the moment, there's no way to specify Typescript compiler options when spawning a Worker, which prevented user from using customized tsconfig.json.
are you looking to have different compiler options in your workers than the rest of your code base?
if you are just looking to add worker type definitions you can use a triple slash directive at the beginning of your worker file.
/// <reference lib="webworker" />
@deebloo I actually wanted to change the jsxFactory value from React.createElement to something else, because I'm trying to use JSX for my own web framework. At the moment, I'm declaring the React namespace, it's kinda awkward because user who wanted to use my library needs to import the React namespace without using it, just to bypass the compiler error.
The framework works by spawning a Worker to run a script (which imports the view code from a .tsx file) that will do rendering whenever the server received a request.
Why wouldn't you just specify it on the command line? (deno run --config tsconfig.json) Why would you want a different one for the worker?
@kitsonk I actually thought of using Deno.run before, but @bartlomieju told me that Deno.run is spawning process, so it can be more expensive and slower than Worker which spawn threads.
But why would your top invocation of deno run --config tsconfig.json need to differ from your new Worker()?
@kitsonk oh ok so you鈥檙e saying if I started my script X with a tsconfig A, the Worker spawn by X will use A?
Just confirmed that this is true. Thanks Kitson.
It feels to me that having a different config for the Worker() from the main module is an edge case. Something we might want to consider in the longer term after we have some major refactors of both the Worker (like structured cloning and the Deno namespace) and the compiler settled, but I would generally consider this a low priority.
Most helpful comment
It feels to me that having a different config for the
Worker()from the main module is an edge case. Something we might want to consider in the longer term after we have some major refactors of both the Worker (like structured cloning and the Deno namespace) and the compiler settled, but I would generally consider this a low priority.