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

validate: allow source/dist for publication #10655

Closed
naderman opened this issue Mar 22, 2022 · 0 comments
Closed

validate: allow source/dist for publication #10655

naderman opened this issue Mar 22, 2022 · 0 comments
Labels
Milestone

Comments

@naderman
Copy link
Member

naderman commented Mar 22, 2022

Typically for VCS repositories we expect the composer.json to be a part of the repository, so composer validate will error if you set a source and/or dist in the composer.json.

However there are some legitimate use cases for using these keys in a composer.json versioned in a VCS repository. As a public (working) example the roots/wordpress package (part of bedrock) uses this to offer a repository versioned with git pointing to wordpress zip download URLs: https://github.com/roots/wordpress/blob/master/composer.json Similarly this mechanism can be used to both reference external non-composer archives and still version these references and metadata with git. So it's something that comes up in Private Packagist a fair bit (e.g. wordpress plugins, moodle plugins, etc).

Another example:

{
    "name": "moodle-plugin/slider",
    "description": "Moodle Plugin that adds a slideshow block type",
    "type": "library",
    "license": "MIT",
    "dist": {
        "url": "https://moodle.org/plugins/download.php/21525/block_slider_moodle38_2020051300.zip",
        "type": "zip"
    },
    "require": {
        "php": "^7.3|^8.0"
    },
}

So I suggest to downgrade setting a dist/source to a warning rather than a publishError. Although I would prefer to see this used only in very few cases on packagist.org where there really is no better workaround, I can definitely see it used more commonly when publishing on some internal platform, e.g. Private Packagist.

@Seldaek Seldaek added this to the 2.2 milestone Mar 29, 2022
@Seldaek Seldaek added the Bug label Mar 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants