Loading a module with `.load_main_es_module_from_code()` and TS module loader doesn't transpile
While working on a script runtime I ran into a curious issue where the main module I load doesn't get transpiled. This may well be my lack of understanding of how
deno_core
crate works but the case seemed so mind boggling to me I created a small repo for reproduction.
The TLDR is:
1. I have a script.ts
that I load and evaluate at runtime.
2. The script.ts
uses functions from a helper library script-api.ts
3. When I load the file using the .load_main_es_module_from_code
method (and evaluate with .mod_evaluate
and run the event loop etc etc) the helper library gets transpiled correctly, however not the main module in question..
Here's my repro repo with a passing and failing examples and a README describing the case in more detail.
Would love to know what am I missing here?GitHub
GitHub - keturiosakys/script-evaluator-repro: Trying to understand ...
Trying to understand why the main module doesn't get transpiled - keturiosakys/script-evaluator-repro
2 Replies
It seems like you've encountered an issue where the main module isn't being transpiled when using
.load_main_es_module_from_code()
in conjunction with a TypeScript module loader. The documentation provides an example of how to create a custom TypeScript module loader that transpiles TypeScript to JavaScript before loading it into the JsRuntime
. Here's a step-by-step breakdown based on the documentation:
1. Implementing a Custom Module Loader: The documentation describes the creation of a TsModuleLoader
struct that implements the deno_core::ModuleLoader
trait. This custom loader is responsible for determining the media type of the file (e.g., TypeScript, JavaScript, JSX, etc.), reading the file content, and transpiling it if necessary.
2. Transpiling TypeScript: The load
function of the TsModuleLoader
uses deno_ast
to parse and transpile TypeScript. It checks if the file needs to be transpiled based on its media type and then performs the transpilation using deno_ast::parse_module
and parsed.transpile()
.
3. Replacing the Default Module Loader: In the JsRuntime
creation, the default FsModuleLoader
is replaced with the custom TsModuleLoader
. This ensures that any TypeScript code is transpiled before being executed by the runtime.
4. Running the Runtime: After setting up the custom module loader, you can run the runtime with cargo run example.ts
, and it should work without any errors related to parsing TypeScript.
Given this information, you should ensure that your custom module loader is correctly set up and that it's being used when creating the JsRuntime
. If the helper library is being transpiled correctly, it suggests that the module loader does work for imported modules. However, there might be an issue with how themain module is being handled.
Here are a few things to check in your implementation:
- Ensure that the
TsModuleLoader
is correctly configured to transpile the main module as well as imported modules.
- Verify that the load
function in your TsModuleLoader
is being called for the main module and that it's returning the transpiled code.
- Check if there are any differences in how the main module and imported modules are being processed by the loader.
If after reviewing your implementation based on the documentation you still encounter issues, it might be helpful to add logging or debugging statements within your TsModuleLoader
to trace the execution flow and identify where the process differs for the main module.
Remember that the documentation provides a general guide on how to implement a TypeScript module loader, but the specifics of your implementation may require additional debugging to ensure that all modules, including the main one, are transpiled as expected. 🦕