search

seaofvoices / darklua

A command line tool that transforms Lua code
https://darklua.com/
MIT License
67 stars 8 forks source link

string requiring siblings without specifying './' errors #197

Open AshleyFlow opened 2 months ago

AshleyFlow commented 2 months ago

as the title says, when you do something like require("sibling") (sibling being a modulescript that's in the same directory), I get an error like this 'error processing <script-name> (bundler): unable to require resource at <sibling>: unknown source name <sibling>', but when you do require("./sibling"), it works just fine.

TLDR

require("sibling") doesn't work require("./sibling") works

the luau lsp extension has no problem with require("sibling"), so I'd expect it to work with darklua aswell... this gets very annoying when I want to add darklua to an already existing codebase

jeparlefrancais commented 1 month ago

I understand the problem, but this was made on purpose back when I added that functionality. The reason behind this choice is that I could not decide where "module" would resolve from. Some environments resolve a path like this from the cwd, some from the current file, some from where dependencies are installed, and some are a mix of all of these in some pre-defined priorities.

I figured it would be simpler to make paths explicitly relative in darklua (or use path aliases). I have not looked at the Luau RFCs in a while, but if there were a specific standard that could be followed for where to resolve paths (and in which priority) that would be a good starting point.

AshleyFlow commented 3 days ago

After looking at the existing Luau RFCs for string requires, Ive came to the conclusion that having to explicitly define "./" in require path is the correct behavior.

however none of the other popular community made tools have followed this rule.

for example both Lune and JohnnyMorganz/luau-lsp try to resolve the path from the current file and not cwd when you do require("sibling") or require("sibling_directory/script") (sibling here implies that the said path is in the same directory as the current file) so basically "./" is attached automatically to the start of the path.

so this raises the question: is Darklua gonna stick to the way of these RFCs, or these other popular community made tools?