[feature request] Support for packages not in VCS to be handled by packagist.org

[njh]

I have a build process for building stable .tar.gz and .zip files, which removes unnecessary files, not needed by composer based consumers of my library - such a test data, documentation etc.

I would also prefer users to use my own HTTP download server, then download from GitHub.

Please can you make it possible to register these repositories with packagist.org, to reduce any extra configuration by the consumer.

[Seldaek]

I don't think we will support this for a while. #99 would be a way to support it too. If you really want to exclude files form the zip archives though you can use the .gitattributes file, see: https://github.com/Seldaek/monolog/blob/master/.gitattributes

[njh]

Yes, that would be great.

Thanks for the tip about .gitattributes files.

[borekb]

Another use case where this would be useful are WordPress plugins (and Drupal modules and other CMS's equivalents as well). There are more and more WP plugins that need a build step, e.g., to transpile JS using Babel or to transpile JSX (React) to plain JavaScript, and there is currently no easy way to support such packages on packagist.

Ideally, I'd like to tell packagist "use our GitHub but look at the 'Releases' section first and download from there". There are quite a few details to work our, for example, how to obtain ZIP files for revisions that are not tagged and built (throw an error there?) but it would be generally very useful to download arbitrary ZIP files instead of full GitHub repositories.

[sminnee]

The ability to either to specify custom dist URLs, or to make use of the github release download URLs, would be very helpful.

We have the same case as @borekb where we have javascript sourced from npm packages and compiled using webpack, babel, etc.

Right now our choices are:

• Force every user of our package to download the individual npm packages and compile locally
• Commit out compiled files into our github repo

We've gone with the latter approach, as the former would be too slow and too much tooling overhead for the normal use of our packages (principally silverstripe/framework and silverstripe/cms). However, it has the following disadvantages:

• Merge conflicts occur on github whenever the minified dist files change
• Large, frequently changing files in our repo are probably bloating out its size
• We rely on contributors re-building these sources before submitting a PR, which they may forget to do

Of these points, the first one is the biggest issue.

An alternative approach would be to move dist files out of the repo, and then do the following:

• For each tagged release, compile the dist files and upload a zip to the releases section of github
• Instruct packagist to provide the dist file from the uploaded release rather than the default zipball
• For modules installed from source, provide a post-install script that ran the npm build process locally

That middle point, "Instruct packagist to provide the dist file from the uploaded release rather than the default zipball", is what's missing.