Can tidelift in github funding.yml have multiple package names?

Just like Github Sponsorship can specify multiple usernames in FUNDING.yml, can tidelift specify multiple packages?

eg https://github.com/airbnb/enzyme is a multirepo with 6-7 packages in ie, but it can only add one of them to the sponsor button.

Unfortunately, GitHub only allows us to have one identifier in the FUNDING.yml; however, our auto-detection of FUNDING.yml just needs to point to one of your lifted packages.

For enzyme, you can use npm/enzyme and it should complete all the “GitHub Sponsors” tasks for each of those lifted packages within the monorepo.

In that case, since you have detection (which is great), why not tidelift: true? That way I wouldn’t have to put a different value in each repo - which would work especially well with an org-wide .github repo.

@ljharb AFAIK the current spec was handed down by GitHub for us to implement. They do the URL expanding on their end.

Sure, but does that mean I can put literally any value in there that maps to a URL you listen to, and your autodetection would kick in?

My understanding is that our auto-validation compares the URL value to any package within your list of lifted packages. So if you were to put rubygems/rails, it wouldn’t validate—but if you put npm/enzyme in any of your own packages, they would.

One reason for this is our support of the community health files for an organization. Often an organization will want to put a single FUNDING.yml in the organization .github repository and that will likely have their most popular project (e.g. https://github.com/gulpjs/.github/blob/master/FUNDING.yml has npm/gulp referenced).

Should we be more strict on how these are validated?

Right, but it doesn’t make any sense to me to put “their most popular project” - if it would be very easy to make it not matter what value is placed here, due to your autodetection, then it would be a lot more user-friendly if it was just “tidelift: enabled” or something.

What is the value of making “notmypackage” fail validation, if you could autodetect “yesmypackage” and make things Just Work anyways?

If I am understanding correctly, I totally agree with you! It would be awesome to have tidelift: enabled but that would require GitHub to change code in their system and can’t be solved by us. We will definitely keep this in mind while we work with GitHub in the evolution of the FUNDING.yml file!

Would it? If GitHub is currently just appending the value to a URL you support - could you, say, add a URL on your end that would currently be the package “true” but with your new route would be detected as “whatever’s auto detected”?

Heads up that this task: https://tidelift.com/lifter/package/npm/eslint-import-resolver-node/tasks/23580 isn’t resolving/autodetecting the sponsor button even though the repo has it set up.

I’ve seen the auto detection work at an org level so far, but haven’t yet seen it work with a single repo with multiple packages.

Hi @ljharb. I could confirm this behavior and I just rolled out a fix for monorepos. Try again.

Thanks, works fine now :slight_smile:

(note that the original question remains; is there any way that all FUNDING.yml tidelift entries could be the same static value, rather than having to be different for every repo?)

This would be a great addition and make the life of many maintainers much easier!

Hope GitHub is open to suggestions like this coming in :blush:

2 Likes

(another FUNDING.yml verification that’s failing, altho not a monorepo: https://tidelift.com/lifter/package/npm/jsx-ast-utils/tasks/23781)

The issue with jsx-ast-utils should now be fixed @ljharb. Try it again.

1 Like