Request: Publish to Composer/Packagist

[joshuabaker]

It’d be great to have this resource available via Packagist.

[ericcornelissen]

I don't see why we wouldn't add this 🤔

Do you have any guidelines/examples/help on how we can best approach that, I'm not a PHP developer myself (I don't know if any of the other maintainers are) so I'm not super familiar with Composer/Packagist

[joshuabaker]

Thanks for being open to this.

The required composer.json file is pretty similar to the existing package.json file.

{
  "name": "simple-icons/simple-icons",
  "description": "SVG icons for popular brands",
  "homepage": "https://simpleicons.org/",
  "keywords": [
    "svg",
    "icons"
  ],
  "support": {
    "issues": "https://github.com/simple-icons/simple-icons/issues"
  },
  "license": "CC0-1.0"
}

Then a maintainer just needs to submit the package to Packagist.

[joshuabaker]

Closing as this isn’t moving.

For those needing to install via Composer, at the time of writing, you can install via asset-packagist.org.

[ericcornelissen]

Closing as this isn’t moving.

I feel like that is something for the people maintaining a repository to decide 🤔 I consider this issue still as a TODO and would therefore like to keep it open. Is the issue being open bugging you as the opener, @joshuabaker?

For those needing to install via Composer, at the time of writing, you can install via asset-packagist.org.

That is actually a great link, thanks for sharing it!

[joshuabaker]

That wording might have sounded passive aggressive. It wasn’t meant to. 😅

In my mind, I have as much responsibility to contribute to open source as repo owners (i.e. opening/closing/owning issues and submitting PRs/solutions). If I can’t, as in this case, it just sits as a perpetual to do in my issues.

There’s a couple of solutions out there right now that support similar packages (i.e. front-end assets, not PHP packages/libraries) so I saw fit to close.

[ericcornelissen]

That wording might have sounded passive aggressive. It wasn’t meant to. 😅

I wouldn't say aggressive, I just didn't see why you'd close it 😉But that's just a difference in style of using GitHub.

In my mind, I have as much responsibility to contribute to open source as repo owners (i.e. opening/closing/owning issues and submitting PRs/solutions). If I can’t, as in this case, it just sits as a perpetual to do in my issues.

I appreciate that mindset, what prevents you from contributing? Time or knowledge? If it is just knowledge, ask us questions! You probably have the exact knowledge we are missing to tackle this issue ourselves.

I would like to keep this issue open and prefer to not open a clone issue 🤔Does it help your perpetual list of issues if this issue is assigned to someone?

[joshuabaker]

I appreciate that mindset, what prevents you from contributing?

Only team members can connect the repo to Packagist, so it’s not something I can do solo.

[ericcornelissen]

Only team members can connect the repo to Packagist, so it’s not something I can do solo.

In that case, if this configuration is truly enough, I will try to get a version published on Packagist. I'll get back to you here when I run into problems 👍

[joshuabaker]

@ericcornelissen Give me a shout if you run into any issues. Happy to help, if I can.

[ericcornelissen]

@joshuabaker I have some questions that are currently preventing me from getting the package out there. Would you mind providing us with some insight?

First I have a couple of questions after reading the documentation.

On About - Managing package versions it says:

New versions of your package are automatically fetched from tags you create in your VCS repository.
[...]
Tag/version names should match 'X.Y.Z', or 'vX.Y.Z', with an optional suffix for RC, beta, alpha or patch versions. Here are a few examples of valid tag names:
1.0.0
v1.0.0
1.10.5-RC1
v4.4.4beta2
v2.0.0-alpha
v2.0.4-p1

That sounds like we need to start using git tags (I'm not necessarily opposed, it's just a change to our current workflow). But then it also says (what I left out above as [...])

The easiest way to manage versioning is to just omit the version field from the composer.json file. The version numbers will then be parsed from the tag and branch names.

Which makes me think it can also be managed in the composer.json file, similar to how it works in NPM.

That would be ideal for us since the releasing commit (i.e. the commit that should be tagged) is created on GitHub, and therefor harder (read "requires more effort") to maintain. Whereas updating composer.json could be part of our version bump commit.

And second:

Branches will automatically appear as "dev" versions that are easily installable by anyone that wants to try your library's latest and greatest, but that does not mean you should not tag releases. The use of Semantic Versioning is strongly encouraged.

Do you know more about this? This short description doesn't really tell me much... Our repository always has two branches (since everyone, including the maintainers, work from forks): master and develop. master contains the "stable" build, and develop is actively being worked on. However, develop is our standard branch so that might confuse Packagist/Composer.

I'm just guessing here and would love some clarification.

---

Two other questions that I couldn't find official docs on:

Excluding files

One is about excluding files from the package. Based on this Stack Overflow answer I think the easiest way to ignore irrelevant files is by adding a .gitattributes file (which I'm all for and have been wanting to look into for a while!) but it doesn't seem to be "the real" solution. It also mentions

That means once you are ready to tag a new release. You trigger your build script, which fetches all the dependencies, runs the tests once more and when everything is ok, drop all the tests and packages the files for deployment.

Which we could do with our CI pipeline, but I'm not sure where the files for deployment go 🤔 Do you know? Would that be a separate repository?

Multiple owners

The other is question is with regards to the "owners" of a package on Packagist. Can there be multiple, can all maintainers be assigned as owner (or at least contributor) of the package and is it possible to transfer ownership to others in some way?

[joshuabaker]

That sounds like we need to start using git tags (I'm not necessarily opposed, it's just a change to our current workflow).

Tagging works with NPM too, if I’m not mistaken. Releases via tags indicate stability and compatibility, help document changes, and allow easier navigation in Github and Git tools. It’s worthwhile considering this approach, in my opinion.

Branches will automatically appear as "dev" versions that are easily installable by anyone that wants to try your library's latest and greatest...

Do you know more about this? This short description doesn't really tell me much...

My understanding is that dev in Composer maps to master by default; However, you can map to dev-master or dev-develop (i.e. dev-{branch}) explicitly.

Excluding files

Why would you need to exclude files? The repo is relatively small so I think it’s fine to download the whole thing. Using laravel/laravel as an example, all the tests etc. get downloaded when installing.

From that Stack Overflow answer: “If it is a small library, stop to worry. Be happy.. :)”

Multiple owners

You can have multiple maintainers, yeah. Once your package is published there’s an option to add maintainers on the package page.

[ericcornelissen]

Tagging works with NPM too, if I’m not mistaken. Releases via tags indicate stability and compatibility, help document changes, and allow easier navigation in Github and Git tools. It’s worthwhile considering this approach, in my opinion.

NPM primarily looks at the version specified in package.json as far as I can tell, and the versions are being tracked by NPM so that is what we're relying on so far (as well as the release labeled Pull Requests.

That said I think we can set up automated tagging (based on the version in package.json?) through Travis CI. I will see if I can update our Travis CI according to the docs and hopefully we will soon see git tagged releases. (relevant for #747)

Once that works I will start looking into adding the composer.json configuration file 👍

[...] However, you can map to dev-master or dev-develop (i.e. dev-{branch}) explicitly.

How can we do that? Or do you mean as a user I can do that?

Why would you need to exclude files? The repo is relatively small so I think it’s fine to download the whole thing. Using laravel/laravel as an example, all the tests etc. get downloaded when installing.

I think that is a matter of opinion 😉 But if the package manager doesn't support it, then it is beyond us. We can always add the .gitattributes file to support those using the --prefer-dist flag.

You can have multiple maintainers, yeah. Once your package is published there’s an option to add maintainers on the package page.

Alright thanks.

[ericcornelissen]

With #1611 merged in develop, we can publish the Packagist after the next release (i.e. when develop is merged into master) 👍

[ericcornelissen]

With the latest release Simple Icons is now available on packagist!