seaofvoices
string requiring siblings without specifying './' errors
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
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.
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?
Ive heard other community made tools are also considering to change their implementation to match the new require rfc (where including ./ in relative path is required)
so I guess its safe to say that we can close this issue