Iterate files in an archive is harder than it should

[Sturez]

Imagine the situation where we have no clue of which files we should get (so no possibility archive.get('filename') ). it would be natural trying to use the Iterator archive.files(). but here the thing:

` const archive = await ZipArchive.from_blob(blob)

  let currentFile = archive.files().next()
  while (!currentFile.done) {
    const [fileName, zipEntry] = currentFile.value
    console.log(fileName, zipEntry)
    currentFile = archive.files().next()
  }

`
the iterator does not move ahead.

for (const iterator of archive.files()) { .... }

Type 'Iterator<[string, ZipEntry], any, undefined>' must have a 'Symbol.iterator' method that returns an iterator.

if I am missing other ways to deal with that, just let me know.

[shortercode]

Hi @Sturez sorry for the slow reply, been adjusting to being a father. Based on your example you are creating a new Iterator ( that starts at the beginning again ) after logging the file. The .files() method doesn't do anything particularly fancy, it returns an IterableIterator from an array of entries.

If you create the Iterator then call next on that it should work correctly.

  const iterator = archive.files()
  let next = iterator.next()
  
  while (!next.done) {
    const [fileName, zipEntry] = next.value
    console.log(fileName, zipEntry)
    next = iterator.next()
  }

I was a little surprised by the type error you posted, it appears to be incorrectly tagged as Iterator instead of IterableIterator. for...of wants something that's Iterable so that it can create it's own Iterator from it. You can correct the type with an cast to get around the issue for the time being. Either Iterable<[string, ZipEntry]> or IterableIterator<[string, ZipEntry]> would be correct.

I've been working on an overhaul of this library in my downtime, I've thrown the fix in there ( it's just a change to the return type ) in the hope it will be faster than swapping lanes to get the fix into the mainline.