How to get acces to import.meta.url info or similar in rust ops

[mash-graz]

I can't figure out, how to get metainformation about the currently processed script resp. the stack of involved scripts from within rust ops?

Does anybody know, where do look for this kind of information?

thanks!

[bartlomieju]

There's no easy way to do that. Could you tell more about the use case you have? Maybe there's another API that would help with the case?

[mash-graz]

If you call createRequire() from an JS/TS module, in wrappers for legacy CJS content, you usually place the value of import.meta.url as argument, to define the base of all relative path entries used in the later require() invocations.

First I was trying to enter the current working directory, but it needs a file location, not a directory, to work correctly.

Now I'm just using the require(...) target itself as argument for createRequire too. This seems to work and its simplicity looks quite attractive and helps to avoid lots of platform specific path handling issues. In this case you simply have to use filename of the script target prefixed by ./ and you have a sufficient relative link with minimal effort. But it's still not the correct way to solve this challenge.

Therefore, I'm looking around, if there could be a better solution without to much complexity.

[bartlomieju]

The easiest and best solution would be to pass the value of import.meta.url to a Rust op - there's really no universal way to get this value in Rust.

[mash-graz]

Passing it from JS/TS looks like a realistic possibility, because you always have to prepare some mediating code on the TS/JS side anyway.

But this question isn't of vital significance anyway. I just puzzled about the problem and couldn't find an answer anywhere, but at the end that's more curiosity.

btw: I spend some time today to watch your video lectures about deno and its internal architecture and development. I learned a lot again! You really should continue communicating this kind of technical introductory lessons even after the Covid related video conference boom. It's extremely helpful for a better understanding of deno, its inner waking and code structure. Some topics (for example the `op2 macro, permission and state handling) are hard to grasp, if you don't get an explanation by those, who use them all the time.