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

fix(ls): Allow string types for type arg & improve type safety #4

Merged
merged 6 commits into from
Apr 20, 2024

Conversation

mitsuki31
Copy link
Owner

Summary

This pull request delivers a set of improvements to the ls function, focusing on flexibility, type safety, and documentation clarity.

Details

APIs Enhancements

  • String Value Support for type Argument:
    Previously, the ls function only recognized lsTypes enum values. This change allows you to use string literals directly corresponding to lsTypes properties for the type argument. This simplifies usage, as shown in the example:

    const files = await ls('./foo', {}, 'LS_F');

    Code above are equivalent with this code:

    const files = await ls('./foo', {}, lsTypes[4]);

    A stricter type checking mechanism has been implemented to prevent unexpected or invalid input for the type argument. This is further supported by the introduction of a dedicated helper function, checkType, for robust type verification.

  • Default Type Resolution Refactor:
    This change addresses a minor internal adjustment related to the default type resolution mechanism within the ls function.

Documentation

The API documentation for the ls function has been comprehensively reviewed and updated for better clarity. Additionally, link references have been added to relevant error classes that might be thrown by the API, providing more context for potential issues.

Test Environments

New test cases have been added to comprehensively cover various scenarios:

  • Allowing null for the options argument.
  • Accepting string values for the type argument.
  • Throwing a TypeError for unexpected type values.

This ensures the function behaves as expected under different input conditions. Additionally, this changes enhances the readability of success test case descriptions within the simpletest library by adjusting their text color.

Benefits

  • Enabling more flexible usage with string value support for the type argument.
  • Enforcing stricter type safety to prevent potential errors.
  • Providing clearer and more informative documentation for developers.
  • Adding comprehensive test cases to guarantee code quality and reliability.

Previously, if using the string value of `lsTypes` enum (e.g., 'LS_F') the `ls` function can't recognizes it correctly and ignore it, thus causing the returned value is the undesired entries result. This change is to address the issue and now the `ls` function correctly recognized the string value of `lsTypes` enum, improving flexibility to the function.

As of this change, you can now call the `ls` function with less code and more flexible:

  const files = await ls('./foo', {}, 'LS_F');
In the last change we have configured the `ls` function to accepts the string value representing the `lsTypes` property names as value of `type` argument. This change brings the type argument checker to more strict and prevent from unintended values. In addition to this change, a new helper function called `checkType` has been defined to checks and verifies the type argument and compare it with the valid types.
This change updated and improved the APIs docs and also added link references for error classes that might be thrown by the APIs.
- Added a test to check whether the `options` argument of APIs allows explicit `null` value
- Added a test to check whether the `ls` function accepts a string value of `lsTypes` property names as value of `type` argument
- Added a test to check the `ls` function correctly throws a `TypeError` if the given `type` argument is an unexpected value
A small change to `simpletest` library, changed the text description color for success test cases to a bit darker, but keep the description color for failed test cases to default white. This allows developers and users to focus on where the failed tests have occurred (if any).
@mitsuki31 mitsuki31 self-assigned this Apr 20, 2024
@mitsuki31 mitsuki31 added patch Patch changes (e.g., hotfix bugs and issues) refactor Refactor changes bugfix Bug or issue fixes labels Apr 20, 2024
@mitsuki31 mitsuki31 merged commit 8c64dc7 into master Apr 20, 2024
3 checks passed
@mitsuki31 mitsuki31 deleted the fix/unrecognized-type-if-using-string-value branch April 20, 2024 17:32
@mitsuki31 mitsuki31 added this to the v1.0.0 milestone Apr 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugfix Bug or issue fixes patch Patch changes (e.g., hotfix bugs and issues) refactor Refactor changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant