Hello,

I am running into a blocking issue regarding a Composer feed that has a connector configured for Packagist.

Currently, packagist.org supports non-standard version names, such as branch names or custom plain-text strings. However, ProGet rejects these packages, seemingly because it strictly enforces the version schema outlined in the official Composer specification (https://getcomposer.org/doc/04-schema.md#version).

While I understand the desire to stick to the strict schema, the Composer specification explicitly states that the version field is not always mandatory and can be inferred in certain scenarios. As the documentation states:

"Optional if the package repository can infer the version from somewhere, such as the VCS tag name in the VCS repository. In that case it is also recommended to omit it."

Since packagist.org leverages this rule and infers versions from VCS (allowing for non-standard versions like branch names), ProGet's strict validation ends up breaking the sync and rejecting these packages.

The Request:
Could ProGet be updated to mirror the same version validation rules and leniency used by packagist.org, specifically taking into account that the version can be optional or non-standard when inferred from VCS?

Impact:
Right now, this strict validation completely blocks the use of ProGet for large projects that rely on upstream dependencies with these non-standard version names. We are unable to successfully proxy/cache these packages.

Thank you for looking into this! Please let me know if you need any logs or further examples.

Hello,

We are experiencing an issue with a Composer feed configured as a proxy for Packagist. While running composer install, our local Composer clients receive a 404 Not Found error specifically when attempting to download the .zip distribution of the package voku/simple_html_dom (version 4.8.10).

Steps to Reproduce:

• Configure a ProGet feed (composer-public-unvetted) as a Composer proxy to Packagist.

• list itemRun composer require voku/simple_html_dom:4.8.10 or include it in composer.json and run composer install.

• The Composer client successfully retrieves the package metadata (JSON) from list itemProGet.

• The client then attempts to download the artifact .zip file.

• The download fails with an HTTP 404 error returned by ProGet.

Diagnosis & Server Logs:
Upon inspecting the ProGet server logs, it appears that ProGet successfully downloads the package from the upstream source but fails to cache it locally. The internal parser throws an InvalidPackageException because it cannot locate the "name" property inside the package's manifest (composer.json). Because the caching process fails, ProGet returns a 404 to the requesting client.

Here is the exact stack trace from the ProGet diagnostic logs:

pg-1  |       Request starting HTTP/1.1 GET http://get.dev.com/composer/composer-public-unvetted/download/voku/simple_html_dom/4.8.10.zip - - -
pg-1  | An error occurred while attempting to cache pkg:composer/voku/simple_html_dom@4.8.10:File is not a valid manifest file.
pg-1  | Inedo.ProGet.InvalidPackageException: File is not a valid manifest file.
pg-1  |  ---> Inedo.ProGet.InvalidPackageException: Missing required property: name
pg-1  |    at Inedo.ProGet.Feeds.Composer.ComposerManifest..ctor(JsonElement root, String version, Boolean cloneElement) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E654949\Src\src\ProGet\Feeds\Composer\ComposerManifest.cs:line 44
pg-1  |    at Inedo.ProGet.Feeds.Composer.ComposerManifest.Inedo.ProGet.Feeds.IPackageManifest<Inedo.ProGet.Feeds.Composer.ComposerManifest>.ReadAndParseMetadataFromPackage(Stream packageStream, PackageInstallContext context) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E654949\Src\src\ProGet\Feeds\Composer\ComposerManifest.cs:line 237
pg-1  |    --- End of inner exception stack trace ---
pg-1  |    at Inedo.ProGet.Feeds.Composer.ComposerManifest.Inedo.ProGet.Feeds.IPackageManifest<Inedo.ProGet.Feeds.Composer.ComposerManifest>.ReadAndParseMetadataFromPackage(Stream packageStream, PackageInstallContext context) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E654949\Src\src\ProGet\Feeds\Composer\ComposerManifest.cs:line 242
pg-1  |    at Inedo.ProGet.Feeds.PackageFeed`5.AddPackageAsync(Stream stream, InstallPackageOptions options, PackageInstallContext context, Nullable`1 publishDate, Boolean listed, CancellationToken cancellationToken) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E654949\Src\src\ProGet\Feeds\PackageFeed.PackageAdd.cs:line 67
pg-1  |    at Inedo.ProGet.Feeds.PackageFeed`5.AddPackageAsync(Stream stream, InstallPackageOptions options, PackageInstallContext context, Nullable`1 publishDate, Boolean listed, CancellationToken cancellationToken) in C:\Users\builds\AppData\Local\Temp\InedoAgent\BuildMaster\192.168.44.60\Temp\_E654949\Src\src\ProGet\Feeds\PackageFeed.PackageAdd.cs:line 152
pg-1  |    at Inedo.ProGet.Feeds.PackageFeed`5.DownloadPackageAsync(TPackage package, IPackageDownloadContext context, OpenPackageOptions options, PackageInstallContext installContext, CancellationToken cancellationToken)
pg-1  | A 404 error occurred in composer-public-unvetted: Package simple_html_dom 4.8.10 not found.
pg-1  | An error occurred processing a GET request to http://get.dev.com/composer/composer-public-unvetted/download/voku/simple_html_dom/4.8.10.zip: Package simple_html_dom 4.8.10 not found.
pg-1  | info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
pg-1  |       Request finished HTTP/1.1 GET http://get.dev.com/composer/composer-public-unvetted/download/voku/simple_html_dom/4.8.10.zip - 404 1230 application/json 127.5770ms

Expected Behavior:

ProGet should accurately extract the composer.json from the upstream artifact, bypass strict validation if upstream parsing differs, or gracefully handle the artifact caching so the Composer client can successfully download the .zip file. The package is completely valid and installs normally when downloading directly from Packagist.

Could you please investigate why the ComposerManifest parser is failing on this specific package and provide a solution or workaround to prevent it from failing the entire cache operation?

Thank you!

Yes, that's all logical. But it completely breaks the approach with promotion. I can't promote a package that doesn't exist.

Why doesn't proget cache the metadata of a package without zip?

Hello.
I keep trying to use composer feed in a real project.
There are packages with the metapackage type in composer. If you install such a package from a feed that has a connector on packagest.org, then such a package is not saved in proget as a local package. There is no corresponding folder in vendors, although it is in composer.lock.

For example:

composer reinstall -vvv --prefer-dist --no-scripts symfony/polyfill-php70

But if you try to download the zip of such a package directly, the package appears.

I think this is a mistake. All packages that are in composer.lock must be stored in proget.

Thank you.