Skip to content
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

Expected warnings in exs files #685

Open
sodapopcan opened this issue Apr 3, 2024 · 2 comments
Open

Expected warnings in exs files #685

sodapopcan opened this issue Apr 3, 2024 · 2 comments

Comments

@sodapopcan
Copy link

For certain special-case files, both .exs files in my case, some syntax is legit that isn't normally considered so.

For example:

In .iex.exs, it's very common to import, alias, or require modules without actually using them. In priv/repo/seeds.exs in a Phoenix project, it's pretty much guaranteed you're going to use your Repo to populate your db. In both cases, Lexical gives warnings. In the former they "unsed import/alias/require" warnings, and in the latter it's "could not look up Ecto repo". An example seeds file would look like:

unless MyApp.Accounts.get_user_by_email("[email protected]") do
  MyApp.Accounts.register_user(%{
    name: "Bob",
    email: "[email protected]",
    password: "Password12345"
  })
end

Of course the warnings in .iex.exs could be silenced by adding warn: false to everything, but that is not ideal (though also not the end of the world). I'm not sure if anything can be done about the repo case. I have noticed wrapping everything in if Mix.env() != :test silences it.

Thanks!

@scohen
Copy link
Collaborator

scohen commented Apr 10, 2024

I've been thinking about this, and this seems like it'd be a project-level configuration option, though I don't quite know how we'd implement it. You'd likely need to figure out which errors you'd like to suppress in which files, maybe using a wildcard pattern, but this strategy seems version-specific, as the error messages change slightly from elixir version to version.

I don't see a path forward with the repo case however.

@sodapopcan
Copy link
Author

That makes sense to me. AFAIC this is a nice-to-have so I thought I would report. It's not the end of the world and there are ways around it. Thanks for giving it some thought, though :)

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

No branches or pull requests

2 participants