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

[WIP] Add funding field to composer.json and composer fund command #8453

Open
wants to merge 3 commits into
base: master
from

Conversation

@naderman
Copy link
Member

naderman commented Nov 28, 2019

Packages can specify a list of funding options each with a type and URL. The type is used to specify the kind of funding or the platform through which funding is possible.

Thanks to the symfony/thanks implementation which uses GitHub funding files https://github.com/symfony/thanks/pull/73/files we decided to add a general funding feature to Composer. This PR is based on the implementation in npm: https://github.com/npm/rfcs/blob/latest/accepted/0017-add-funding-support.md and npm/cli#273 which has its roots in various previous projects/ideas/experiments: https://github.com/npm/rfcs/blob/latest/accepted/0017-add-funding-support.md#prior-art

Still missing, now that the field is supported and loaded and saved everywhere:

  • composer fund command which outputs a list of funding URLs for all the packages you have installed, grouped by vendor/package/URL
  • adding an output line to composer update/install which informs you how many of your installed packages have funding information and to run composer fund to get information on how to fund those packages
  • support on packagist.org composer/packagist#1052
  • support for loading .github/FUNDING.yml information via GraphQL API in GitHubDriver if no funding information is defined in composer.json
You can specify a list of funding options each with a type and URL. The
type is used to specify the kind of funding or the platform through
which funding is possible.
@naderman naderman force-pushed the naderman:funding branch from e075b3a to b7ffe5c Nov 29, 2019
"description": "A list of options to fund the development and maintenance of the package.",
"items": {
"type": "object",
"properties": {

This comment has been minimized.

Copy link
@stof

stof Nov 29, 2019

Contributor

I would add "required": ["type", "url"] here, to ensure that each item in this array has these 2 properties set. IMO, it does not make sense to allow an item without type or without url.

This comment has been minimized.

Copy link
@naderman

naderman Nov 30, 2019

Author Member

@stof Reasoning was as follows: We can technically infer the type from most URLs e.g. github for github sponsors urls, tidelift for a tidelift package url, patreon for a patreon user url, but we may not always be able to, so documentation says you should define it, but maybe we change our mind in a future composer version?

I don't want to make not having a URL a failure right now since that would mean if we ever add support for other ways of specifying funding than a URL in the future, old composer versions will error on those new packages.

I'm a bit unclear on where we actually have to use loose validation to be reasonably compatible with future changes, the schema, the validating array loader, the regular array loader - cc @Seldaek

This comment has been minimized.

Copy link
@Seldaek

Seldaek Dec 1, 2019

Member

ConfigValidator is the best place IMO as that only impacts the validate command. ValidatingArrayLoader is used in some contexts to load package data while validating it, so that'll break stuff like packagist updates.. same for schema it'll potentially break more places.

@alcohol

This comment has been minimized.

Copy link
Member

alcohol commented Dec 2, 2019

Do we want to add an optional flag similar to --no-suggests, e.g. --no-funding in this case?

@naderman

This comment has been minimized.

Copy link
Member Author

naderman commented Dec 2, 2019

@alcohol since this only prints those two lines with how many packages there are / how to get info, rather than listing all the URLs, I'm not sure we even need that?

Co-Authored-By: Andreas Möller <am@localheinz.com>
@alcohol

This comment has been minimized.

Copy link
Member

alcohol commented Dec 2, 2019

I'm definitely not saying we need this. But I can imagine some people will ask for this. Merely asking if we want to anticipate this preemptively or simply wait and see how we deal with it if and then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.