Hey, sorry for not getting back to you earlier.. Is there no way to make this search faster? Scanning all files is kind of crazy. I would say at least that if it finds a "composer.json" at the root or within one directory depth (because github archives usually have a directory and then the contents) it should just take that and stop. It should eliminate most if not all of those problematic archives and allow the scanning process to complete faster.

Apologies - previous comment was incorrect.

Testing all the file names shouldn't be an issue, as so long as the zip archive is not modified, the zip library has a central list of all the files it contains, with their file names, so it shouldn't have to scan any file or do any file seeking, to iterate over all the files.

I can do a test to see if it does.

What I mean is more that some archives can have thousands of files, and iterating through thousand of file names to check if they match X is sure not super slow if there is only IO once but it's still wasteful and if you have 100 archives to scan before even starting an update it can waste some substantial amount of time. At the very least it should abort once it found a "composer.json" at the root of the archive, because there is really no reason to continue at that point.

Hi,

I noticed this is still open. I've done a test and my computer scans 500 zip artifacts in 2 seconds.

At the very least it should abort once it found a "composer.json" at the root of the archive,

That will almost never occur - most zipballs seem to have files in a sub-directory rather than the root of the archive, but it's not apparently guaranteed.

cheers
Dan

@Danack fair enough it's probably not wasteful enough to be a problem, but accepting invalid packages still is a bit nasty IMO (granted the current code isn't correct either). Doing this would be better, if you have time to update the PR:

• Look in the root dir if there is a composer.json
• If not, loop through dirs at the root, look in them for $dir/composer.json
• If nothing found, abort since it's an invalid package.

Hi @Seldaek,

I've updated it so that it:

• Looks through the list of files once
• A composer.json in the root will be used immediately.
• A composer.json in a first level dir will be used if no composer.json is found at the root.

btw not sure what your standard is for either generating 'fixture' files required for testing dynamically vs documenting how they're generated, so I added the comment of how to generate the added test files.

cheers
Dan

Looks fine to me, thanks. I'd say the generating code is probably not necessary but in the test suite I don't care as much.