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(encoding): Fix malfunctioning encoding option #7

Merged
merged 2 commits into from
Apr 27, 2024

Conversation

mitsuki31
Copy link
Owner

Overview

This pull request addresses an issue with the encoding option in the ls function, where it was previously malfunctioning and limited to certain encodings such as 'utf8', 'binary', and 'ascii'. The issue caused errors when using other encodings such as 'hex'. The problem has been resolved, and the encoding option now works as expected, allowing for more flexibility and robustness in encoding file paths.

Details

APIs Enhancements

  • Resolved the malfunctioning of the encoding option in the ls function, which previously only supported a limited set of encodings.
  • The issue stemmed from internal errors when using encodings such as 'base64', leading to invalid path errors.
  • The problem has been fixed by improving the resolution logic of the encoding option and implementing the encodeTo internal function to handle encoding and decoding of file paths.
  • The encoding option now supports a wider range of encodings and works as expected, providing users with more flexibility in encoding file paths.

Let's assume you have a tree directory like this:

.
├── foo.js
├── README.md
└── LICENSE.txt

And you have this code inside the foo.js file to list the directory with 'base64' encoding:

// foo.js
const { ls } = require('lsfnd');
// Or ESM:  import { ls } from 'lsfnd';

ls('.', { encoding: 'base64' }).then((res) => console.log(res));

Before this change, you might see an error like this:

Uncaught Error: ENOENT: no such file or directory, stat ...

But, after this change now you can see the expected result:

[ 'TElDRU5TRS50eHQ=', 'UkVBRE1FLm1k', 'Zm9vLmpz' ]

Test Environments

  • Added new test cases to thoroughly test the encoding option in various scenarios, ensuring its functionality and reliability.

Summary

This pull request resolves an issue with the encoding option in the ls function, improving its functionality and reliability. With these changes, users can now specify a wider range of encodings, allowing for more flexibility in handling file paths.

Previously, the encoding option are fully malfunctioned and can't be passed with other encodings except 'utf8', 'binary', and 'ascii' (in some cases). If we specify with 'hex' encoding, the function will throws an error (which is due to internal error) complaining an invalid path on the specific entry. Now it has been resolved and work as expected, thankfully to `encodeTo` internal function to encode the entries and vice versa, this also includes improving the resolution logic of `encoding` option to more strict and robust.
@mitsuki31 mitsuki31 self-assigned this Apr 27, 2024
@mitsuki31 mitsuki31 added patch Patch changes (e.g., hotfix bugs and issues) refactor Refactor changes bugfix Bug or issue fixes labels Apr 27, 2024
@mitsuki31 mitsuki31 merged commit 3686a6e into master Apr 27, 2024
3 checks passed
@mitsuki31 mitsuki31 deleted the fix/encoding-option-bad-logic branch April 27, 2024 16:00
@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