Add composer.json to let PHP developers to keep track of chosen on packagist.

[fabiomontefuscolo]

Hello,

This refers to issue #2802.

If you accept this PR, there are another 3 steps. Unfortunately, I can't do it for you.

1. Create an account on packagist.org.
2. Submit https://github.com/harvesthq/chosen-package.
3. Connect github webhooks to packagist.

I'm unsure, but I think this file should live in chosen-package.

Thank you!

[landsman]

Yeah! @pfiller, @kenearley, ... please merge it.
We will very grateful for it in Drupal community!

[koenpunt]

I have no opinion here, didn't know composer was being used for non-php projects. Also I don't think I can help out with creating an account on Packagist for this package, since I'm not the owner.

So @pfiller, what do you think about this?

[tjschuck]

Literally have never heard of any of this, but I haven't worked with PHP in many, many years.

@koenpunt Is this something you'd recommend doing? We've discussed trying to get into assorted other package managers over the years, but that seems like an uphill battle that will never be won, since they seem to pop up constantly, and we've so far been conservative about littering .json files all over Chosen to hit all of them. But if this is the one to do for a wide swath of people (and has proven itself to have legs and won't be replaced in 3 months), we can look into it.

/cc @stof who I think does a lot of PHP.

[stof]

@tjschuck I'm quite against registering non-PHP code on Packagist, as it then leads to cases where people are asking us to add features in composer which are totally useless for PHP packages.
I'm much more in favor of using both composer and npm when a project needs both PHP and JS dependencies. However, I know that this is not a solution for projects like Drupal (especially when they have a PHP dependency being the one needing chosen as it extends Drupal to apply chosen)

[stof]

and if we do it, the repo being registered on Packagist must indeed be the one containing built code

[landsman]

I think that composer.json file can be more useful for another projects that Drupal-based only. Here is example of competing solution like the Chosen: https://github.com/select2/select2 and it have composer.json file, guess why :-) CMS using it easily.

[fabiomontefuscolo]

Please, take a look on examples below. These are all javascript libraries, ready to be part of other libraries, CMS and frameworks.

https://packagist.org/packages/twbs/bootstrap
https://packagist.org/packages/components/jquery
https://packagist.org/packages/components/jqueryui
https://packagist.org/packages/blueimp/jquery-file-upload
https://packagist.org/packages/ckeditor/ckeditor
https://packagist.org/packages/mbostock/d3
https://packagist.org/packages/tinymce/tinymce
https://packagist.org/packages/moment/moment
https://packagist.org/packages/plotly/plotly.js

[fabiomontefuscolo]

I forgot to say about built code. Packagist can read github releases page, so if your library is ready to use after download, probably is ready to join packagist also. No needs to modify your pipeline.

[koenpunt]

I'm not against, but still I'm not the one that can set this up on packagist I believe. Also the indentation in the composer.json is off (mixed 2 and 4 spaces), so please update that.

[stof]

@fabiomontefuscolo Composer is not able to use custom artifacts attached to github releases. So it would still have to use the chosen-package repository storing the build output

[fabiomontefuscolo]

Ok, first thing is about compose.json it self. I fixed white spaces, but build is broken now. Second, I think it is ok composer fetch release from chosen-package, because it is better than handle several packages managers for a single software. On this way, other PHP developers can create their pipelines using just composer.json and avoid npm, yarn, bower, grunt, gulp and other tools that emerge every day.

[stof]

but then, this PR is adding the file in the wrong place, as it adds it in the root of the chosen repo, not in the location being used to build the content of chosen-package.

[marclaporte]

Is this the solution?
https://packagist.org/packages/components/chosen
components/chosen@37d3486

[landsman]

I don't understand where is problem. If you add composer.json immediately there would be great way to define dependency in php projects. Can someone from @harvesthq hive some review, comments to this please?

@stof I don't agree. It's on right place. Must be in root.
@marclaporte I don't want using some fork.

[stof]

@landsman but it must be at the root of chosen-package, not of chosen.

With the existing location, it won't be in chosen-package at all

[tjschuck]

@landsman Please note that though @stof doesn't work at Harvest, he is a maintainer of Chosen. He's also correct that composer.json won't end up in https://github.com/harvesthq/chosen-package based on this PR. You'd need to update the Gruntfile to copy this to the release repo, probably in the copy task.

[landsman]

The composer.json file should reside at the top of your package's git/svn/.. repository, and is the way you describe your package to both packagist and composer.

• https://packagist.org/about#how-to-submit-packages

Packagist don't fetch released package but whole repository.

[koenpunt]

@landsman https://github.com/harvesthq/chosen-package is the source repo for distribution, so packagist should always refer to that one, instead of the main repo (this one)

[landsman]

Thanks @koenpunt I got it. I sent new pull request with these changes.
@stof can you check it please?
Who can create account and submit package to packagist.org under @harvesthq?

[tjschuck]

I have created a harvesthq account on https://packagist.org in preparation.

[tjschuck]

Also, I'm going to close this in favor of #2988 — please continue any discussion over there.

[tjschuck]

Done! https://packagist.org/packages/harvesthq/chosen