Skip to content

Conversation

mochaaP
Copy link
Contributor

@mochaaP mochaaP commented Oct 14, 2025

Store the original file path in module_loader_opaque, let normalize
function read from that and store a normalized filepath in context
opaque, and make module loader read from the filepath from that.

Make it possible to preserve the custom script name while resolving
from another path.

Split from #1187

Store the original file path in module_loader_opaque, let normalize
function read from that and store a normalized filepath in context
opaque, and make module loader read from the filepath from that.

Make it possible to preserve the custom script name while resolving
from another path.
@mochaaP mochaaP mentioned this pull request Oct 14, 2025
@bnoordhuis
Copy link
Contributor

It's not immediately obvious to me what this accomplishes. Or perhaps I should say: it's sort of obvious what it does, but not why (or when) that's useful.

@mochaaP
Copy link
Contributor Author

mochaaP commented Oct 14, 2025

Useful if you want to strip the file path from compiled bytecode / make module resolution independent to script name & cwd

Originally qjsc /path/to/script.js -n script.js searches ./, this makes it search /path/to/

@bnoordhuis
Copy link
Contributor

Okay, that makes sense on the face of it. The code in this PR is really fragile-looking though. Maybe there's a way to improve the module loader API to make that easier. What information do you need when?

@mochaaP
Copy link
Contributor Author

mochaaP commented Oct 16, 2025

It's possible to remove the Set/GetRuntimeOpaque by making normalize return a struct.
I think setting the module_loader_opaque is unavoidable because otherwise we have to change all Eval interfaces to accept an extra realpath argument.

@bnoordhuis
Copy link
Contributor

A while ago we added versions of JS_Eval and JS_EvalThis that take an extensible struct JSEvalOptions, precisely so we can extend the API without making it too cumbersome to use.

Having said that, I can't really gauge how broadly useful this feature is. I don't want to end up with something that only has a single user. In what real world scenario do you envision using it?

@mochaaP
Copy link
Contributor Author

mochaaP commented Oct 20, 2025

I initially wrote this for the meson codegen PR, since run_command cannot specify cwd, and I would like to make generated files the same as make codegen produces.
It's not absolutely required, most of the time this can be replaced by using a slightly more complex directory setup and a wrapper script, but it's a nice addition to have this built-in to qjsc.
since 1. the "build using regenerated sources" option was not merged 2. maintainers always use makefile 3. I have no idea how library consumers can use qjs in what ways, this is optional to have.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants