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

data property in directories is not undefined #16

Open
ayuhito opened this issue Aug 29, 2024 · 0 comments
Open

data property in directories is not undefined #16

ayuhito opened this issue Aug 29, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@ayuhito
Copy link

ayuhito commented Aug 29, 2024

Environment

Node.js 18
nanotar: 0.1.1

Reproduction

"data": "<hidden>",

That may be unique to how the test was made, but otherwise you'll still get a defined empty Uint8Array. e.g.

Describe the bug

The documentation states:

data field is optional for directories and can be either a String, ArrayBuffer or Uint8Array.

image

I would have assumed a directory check could be done with if (file.data) but that isn't the case (including the JSDoc comments which states "file data (don't provide for directories)".

Instead it is if (file.data && file.data.length > 0) since the type for data is still marked as nullable but will send an empty array instead.

Additionally:

Parsed files array has two additional properties: size file size and text, a lazy getter that decodes data view as a string.

export function parseTar(data: ArrayBuffer | Uint8Array): TarFileItem[] {

The parse functions return TarFileItem[] instead of ParsedTarFileItem[] which makes the TypeScript compiler believe these should be inaccessible. I'm not sure if these are intentionally inaccessible, but I think relying on file.type === 'directory' and file.type === 'file' is far more intuitive for differentiating these types.


I didn't make a PR since I think there are multiple API inconsistencies, so it might make sense to get a clear answer from a maintainer before making a change. Whether it is just an invalid property error, type error, or both.

Thanks for the awesome library!

Additional context

No response

Logs

No response

@ayuhito ayuhito added the bug Something isn't working label Aug 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant