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. 🦕