Skip to content

Feature: find .env files in parent directories #518

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
1 task done
teleivo opened this issue Jan 31, 2025 · 4 comments · Fixed by #510
Closed
1 task done

Feature: find .env files in parent directories #518

teleivo opened this issue Jan 31, 2025 · 4 comments · Fixed by #510
Labels
enhancement New feature or request

Comments

@teleivo
Copy link

teleivo commented Jan 31, 2025

Issues

  • I have checked existing issues and there are no existing ones with the same request.

Feature description

Hi 😄 and thank you for your work on this amazing plugin 🥳

I discovered that :Rest env select searches downward from the current buffer's directory. That is surprising to me as most tools search upward stopping at the project root like when finding a .git directory. find_env_files searches downward due to

end, { limit = math.huge, type = "file", path = "./" })

(https://neovim.io/doc/user/lua.html#vim.fs.find() upward=false by default)

This prevents me from reusing .env files at the root of a project with .http files in nested dirs. I can only make it work if I keep the :cd at the project's root. However, that adds .env files in nested dirs that are irrelevant IMHO.

Imagine a project with

  • .env

  • ./a

  • ./a/.env

  • ./a/a.http

  • ./b/b.http

  • When opening b.http from directory ./b (or doing :cd ./b) the root .env is not shown in the select UI.

  • When opening b.http from the root dir ./a/.env is shown in the select UI while from my point of view, its meant to be scoped to ./a

I assume you are open to changes here due to your comment

https://github.com/rest-nvim/rest.nvim/blob/62606c3599bd304227457d6e20580965939b191e/lua/rest-nvim/dotenv.lua#L61C1-L62C63

😋

Changing the search direction is a breaking change so I wonder if we could make this

https://github.com/rest-nvim/rest.nvim/blob/62606c3599bd304227457d6e20580965939b191e/lua/rest-nvim/dotenv.lua#L58C1-L58C28

a configurable function with this one staying the default? Maybe you also have different suggestion 👌🏻

Please let me know what you think! I could give it a try at implementing it if you would want. Thank you again!!

@teleivo teleivo added the enhancement New feature or request label Jan 31, 2025
@teleivo
Copy link
Author

teleivo commented Feb 3, 2025

This is a sketch of the find_env_files I would want to be able to configure

---Find a list of environment files starting from the current directory
---@return string[] files Environment variable files path
function M.find_env_files()
    -- We are currently looking for any ".*env*" file, e.g. ".env", ".env.json"

    local start = vim.api.nvim_buf_get_name(0)
    local git_dir = vim.fs.root(0, ".git")
    -- vim.fs.find stop is exclusive meaning the stop dir will not be searched so I'll get its parent
    local stop = vim.fs.dirname(git_dir)
    local files = vim.fs.find(function(name)
        return name:match(config.env.pattern)
    end, { limit = math.huge, type = "file", path = start, stop = stop, upward = true })
    return files
end

The stop might need a safe default but in my case .http files are always in a .git repo. That's obviously the users choice/responsibility if that function lives in the users config.

@boltlessengineer
Copy link
Contributor

Uh oh... Yeah I agree that it is wrong design.
I think we can just make a breaking change to fix this. Although it is a breaking change on behavior, it will be fine to have just minor version upgrade as it is not working as intended.

@teleivo
Copy link
Author

teleivo commented Feb 10, 2025

Uh oh... Yeah I agree that it is wrong design. I think we can just make a breaking change to fix this. Although it is a breaking change on behavior, it will be fine to have just minor version upgrade as it is not working as intended.

Thank you @boltlessengineer for making it configurable 😄! Will you make the change in behavior later? AFAIK it behaves the same way as before 🤔

@boltlessengineer
Copy link
Contributor

Oh I forgot to take a note about it here sorry about that.
I changed my mind and decided to keep current semantic versioning rules.

The current behavior will be change to search upward until cwd in upcoming v4 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants