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

Is it possible to let luacheck know about/find imported files? #68

Closed
DidierMalenfant opened this issue May 20, 2022 · 6 comments
Closed
Labels
wontfix This will not be worked on

Comments

@DidierMalenfant
Copy link

When using something like the Playdate SDK, a given Lua file will import others like so:

import 'CoreLibs/graphics'
import "CoreLibs/string"
import "CoreLibs/strict"

but it seems like luacheck doesn't support/know about the import statement and therefore those files are ignored. This generates incorrect warnings like so:

    Source/main.lua:44:5: accessing undefined variable assert
    Source/main.lua:79:22: accessing undefined variable string

What is the best way to make luacheck aware of what those import files contain?

@alerque
Copy link
Member

alerque commented May 20, 2022

Luacheck doesn't evaluate code. In order to do what you are suggesting it would have to be a Lua VM and run the code — there would be no other way to effectively catch all the ways code could be loaded. This isn't going to happen.

The way to deal with these warnings in your project is to define an allowed list of globals in your .luacheckrc. That being said it is a bit surprising that your are getting warnings for string, and assort as those are standard Lua builtins. Are you using any Lua presets at or do you have them cleared for use with Playdate? Or do we perhaps need a default configuration that covers Playdate variables by default?

@DidierMalenfant
Copy link
Author

Luacheck doesn't evaluate code. In order to do what you are suggesting it would have to be a Lua VM and run the code — there would be no other way to effectively catch all the ways code could be loaded. This isn't going to happen.

That makes sense. I was thinking more of a parsing solution where luacheck could be told to parse those files first so that it has context before parsing the code using the SDK.

The way to deal with these warnings in your project is to define an allowed list of globals in your .luacheckrc.

That's the direction I was heading in. I just wanted to make sure I wasn't doing anything stupid before adding the entire SDK to my luacheck.rc.

Are you using any Lua presets at or do you have them cleared for use with Playdate? Or do we perhaps need a default configuration that covers Playdate variables by default?

I simplified the case but just running luacheck from the cmdline without any config file and you are correct those are not causing warnings anymore. So my .luacheckrc is what is causing the problem here. User error :)

std = {
    globals = { "playdate" }, -- these globals can be set and accessed.
    read_globals = { "import" } -- these globals can only be accessed.
}

@alerque
Copy link
Member

alerque commented May 20, 2022

Try not overwriting the std declaration:

std = "min",
globals = { "playdate" }, -- these globals can be set and accessed.
read_globals = { "import" } -- these globals can only be accessed.

Change min to suite the version equivalent the Playdate SDK uses as a base, for example lua52 or lua45 or luajit.

If there are more things in the SDK that aren't covered by those presets, rather than you adding the whole SDK to a preference file lets setup a custom set of standards. For example we have existing ones for LÖVE and NGX as well as a busted mixing to add to any of the above. See the src/luacheck/builtin_standards/ directory for where these names are coming from.

Also luacheck --help has information about things you can use as std in your RC file or --std from the command line.

@alerque
Copy link
Member

alerque commented May 20, 2022

The "follow imports" issue is basically the same as #36 and won't be addressed.

Adding a set of defaults for Playdate is definitely something we'd consider. I'd be happy to facilitate a PR that added support similarly to the way LÖVE or others are handled. Feel free to open a tracking issue specific to that and/or submit a PR.

@alerque alerque closed this as completed May 20, 2022
@alerque alerque added the wontfix This will not be worked on label May 20, 2022
@DidierMalenfant
Copy link
Author

Adding a set of defaults for Playdate is definitely something we'd consider. I'd be happy to facilitate a PR that added support similarly to the way LÖVE or others are handled. Feel free to open a tracking issue specific to that and/or submit a PR.

I'd be happy to look into that. Thanks for the help and keep up the great work.

@alerque
Copy link
Member

alerque commented May 20, 2022

On the subject, be sure to see #53 about operators and the recent PR to add them in #66. You might find people interested in helping collaborate on a set of presets for Playdate as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Development

No branches or pull requests

2 participants