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

Refactor: support includes & excludes #83

Open
evaera opened this issue Nov 1, 2021 · 1 comment
Open

Refactor: support includes & excludes #83

evaera opened this issue Nov 1, 2021 · 1 comment

Comments

@evaera
Copy link
Owner

evaera commented Nov 1, 2021

Started working on this today, turns out it's a little bit more complicated than originally thought.

Next time I (or someone) works on this problem, these are the steps that need to be taken:

  • Start loading the moonwave.toml file from the Rust extractor side (this means making a struct and using serde_toml to load it)
  • Pull in new include and exclude properties from the toml file
  • Use the ignore crate to build up includes and excludes (docs) (how cargo does it)
  • moonwave extract takes a path to search for lua files in, and also has an option for base_path, which all relative paths are relative to. We should remove the main path parameter, and upgrade the base_path option to a positional argument where the old one was.
  • Then, we use that base path to look for moonwave.toml, load the config file, and see what files should be included. If there is no moonwave.toml, we use the base path as the path to search for files in, with a default include of *.lua.
  • Use walkdir on all included paths and check the results against the excludes to see if a path should be used

Open questions

  • Should we still gate on .lua files? This is realistically what everyone would want, but technically makes the globs in includes no longer accurate

Gitignore files

We should also probably use the files listed in .gitignore to automatically ignore files if the user doesn't specify an ignore property or doesn't have a moonwave.toml. This is rather complicated, because:

  • There can be more than one .gitignore file
  • There can be nested .gitignore files
  • Gitignore files can contain negative globs (e.g., exclude all files in this folder, but include this one specific one)
  • There is a system-wide global gitignore file

Because of the complexity of parsing gitginore files, we need to include libgit2 and use it to list all tracked files in the project to form a whitelist to know what files we should include. Importantly, we should not require the user to be using Git in their project, so we need to be able to fail gracefully and not ignore anything.

Given that this part is somewhat complex, we should implement this issue in two parts. Once the include and exclude properties are implemented, we should open a new issue for parsing gitignore files as well.

@Quenty
Copy link
Contributor

Quenty commented Nov 1, 2021

Should we still gate on .lua files? This is realistically what everyone would want, but technically makes the globs in includes no longer accurate

I would say that [include] should default to *.lua in the toml. If the user overwrites that, it's on them. That way, we preserve the "globs are accurate" and at the same time, have reasonable default behavior out of the box.

This also means users will have full control over the content.

100% agree on not using .gitignore for alternative options. You can copy the syntax if you choose (although I would say make it toml specific), but doubling up .git functionality with other functionality is a recipe for sadness later on.

Let me know if there's anyway I can support this. I need this to use moonwave in personal projects.

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

No branches or pull requests

2 participants