You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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:
include
andexclude
properties from the toml fileignore
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.*.lua
.Open questions
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: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
andexclude
properties are implemented, we should open a new issue for parsing gitignore files as well.The text was updated successfully, but these errors were encountered: