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

Rewrite require and luaurc in lune-std #247

Open
wants to merge 35 commits into
base: main
Choose a base branch
from

Conversation

FlowGnarly
Copy link

@FlowGnarly FlowGnarly commented Aug 25, 2024

Highlights of this PR

API Changes

for the existing crates that use lune-std nothing has to be changed, since this pr only changes the internal code and adds 2 new items which are totally optional and can be accessed by other crates, which are:

pub trait StandardLibrary
where
    Self: Debug,
{
    fn name(&self) -> &'static str;
    fn module<'lua>(&self, lua: &'lua Lua) -> LuaResult<LuaMultiValue<'lua>>;
}
pub struct RequireContext {}

impl RequireContext {
    pub fn inject_std(
        lua: &Lua,
        alias: &'static str,
        std: impl StandardLibrary + 'static,
    ) -> Result<(), RequireError>;
}

Copy link
Collaborator

@filiptibell filiptibell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the PR! I have not yet made comments on any specific files because I wanted to bring a few general points up. First, the positives:

  • The improvements in error handling and the more strongly typed errors are great. I believe this to be the main highlight of this PR.
  • The new library trait is a good change for flexbility and I hope we can also use it in the future for package management or something similar.

And then, a couple negatives:

  • There are areas where this new implementation introduces TOCTOU race conditions, due to the heavy usage of fs::try_exists. It is very important that if a file read succeeds, we use the contents of the file at that specific moment in time.
  • Rewriting LuauRc fully and removing every field but the aliases one may have been a step too far. It would be nice if Lune could help the user in case they have an invalid config and tell them what is wrong with their fields other than just the aliases. We just needed better error propagation.

Finally, some nitpicks. Feel free to ignore them and wait for me to comment on the specific files and locations if you wish:

  • We can use the path utils from lune_utils::path instead of re-implementing new versions in lune-std.
  • In many cases the new error propagation, which is great, introduces allocation when not necessary. Try to use ok_or_else instead of ok_or when creating the error needs allocation.

@FlowGnarly
Copy link
Author

Hey thanks for the feedback! I really appreciate it

There are areas where this new implementation introduces TOCTOU race conditions, due to the heavy usage of fs::try_exists. It is very important that if a file read succeeds, we use the contents of the file at that specific moment in time.

Ive changed quite alot of code to get around this, it should be good now 😅

Rewriting LuauRc fully and removing every field but the aliases one may have been a step too far. It would be nice if Lune could help the user in case they have an invalid config and tell them what is wrong with their fields other than just the aliases. We just needed better error propagation.

I had no idea why we we're de-serializing all those fields hence I didn't include them in the rewrite, I've bringed back all the fields into the struct so it should be good now (excluding the paths field, because I couldn't find it in any luau rfc, what's that about?)

We can use the path utils from lune_utils::path instead of re-implementing new versions in lune-std.

I didn't know we had all those functions in lune_utils lol, I've removed all the duplicate functions and replaced them with the lune_utils path functions

Try to use ok_or_else instead of ok_or when creating the error needs allocation.

Done!

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