`require` doesn't respect the order of paths in `runtimepath` option

[younger-1]

require obtains module by searching path in a way that doesn't respect the order of paths in runtimepath option.

This behavior is caused by get_runtime_file function which may cache some path that would take precedence over other paths in rtp.

https://github.com/lewis6991/impatient.nvim/blob/bcc22509bdf1c9d9e63e5e44ad00f5fcf581d651/lua/impatient.lua#L121-L148

Test case

Saying the rtp is like following:

/home/xavier/.config/nvim
/etc/xdg/nvim
/home/xavier/.local/share/nvim/site
...

If I have these files in my rtp:

file 1. "/home/xavier/.config/nvim/lua/foo/bar.lua",
file 2. "/home/xavier/.local/share/nvim/site/lua/foo/init.lua",
file 3. "/home/xavier/.local/share/nvim/site/lua/foo/bar.lua",

First require('foo') and then require('foo.bar'), the intended behavior is that file 2 and file 1 will be loaded. file 3 will not be used because it has lower priority than file 1 in rtp.

But impatient breaks this mechanism here, as file 2 is cached first and would take precedence over other paths in rtp.

[younger-1]

I try to fix the problem in https://github.com/younger-1/impatient.nvim/commit/08bb6cf9635d25b22dea3ac08f8dc378d2629f0d, I simply use vim.api.nvim_get_runtime_file which may be faster (I guess) than origin vim.api.nvim__get_runtime.

C function of vim.api.nvim_get_runtime_file: https://github.com/neovim/neovim/blob/ebad151a2a1943ca0d4e07485c416e0762f7f096/src/nvim/api/vim.c#L513-L539

C function of vim.api.nvim__get_runtime: https://github.com/neovim/neovim/blob/ebad151a2a1943ca0d4e07485c416e0762f7f096/src/nvim/api/vim.c#L560-L569

[lewis6991]

This is expected behaviour. If using Lua, you should not be reliant on rtp ordering.

[lewis6991]

And vim.api.nvim_get_runtime_file is much slower than nvim__get_runtime.

[younger-1]

This is expected behaviour. If using Lua, you should not be reliant on rtp ordering.

Thanks for your reply! May I ask what are the chances this reliant would be guaranteed by neovim in the future, in your opinion?

[lewis6991]

In regards to Lua, I don't know. The core devs might decide that a fast resolution time is more valuable than guaranteed ordering.

[lewis6991]

I've added the ability to disable the module resolution cache. If you rely on the ordering, then there isn't any optimisation we can make around module resolution.

[younger-1]

Thanks very much！