search

desandro / draggabilly

:point_down: Make that shiz draggable
https://draggabilly.desandro.com
MIT License
3.86k stars 387 forks source link

Added composer support and release excludes. #127

Closed mkungla closed 6 years ago

mkungla commented 8 years ago

Added .gitattributes to ignore set of files and directories for upcoming releases. These files are still included for tags, but not included in release archives (.zip and .tar.gz). Modified gitignore: composer vendor, composer.lock dir/file.

Added initial production ready composer.json which should be submitted https://packagist.org under user desandro. composer 'extras' parameter makes it compatible with Component Installer for Composer: https://github.com/RobLoach/component-installer

Since Draggabilly can be installed with npm and bower and possibly with composer then current state could be considered to be submitted as Composer component components/draggabilly: https://github.com/components/components/issues

Could resolve #126

desandro commented 8 years ago

Thank you for this contribution. I'm not keen on adding support, but I'd like to see if others are interested.

+1 or add a 👍 reaction if you would like to see Composer support added for Draggabilly,

mkungla commented 8 years ago

About composer support

I don't understand what you mean with that.

I don't quite understand that requires its own login, authentication, and maintenance

It does require you to login (can just login with your github account) once to submit once your package and set up GitHub Service Hook to automatically update releases from github there on. There is no other maintenance required. But I can see that this opinion might come since you have not set the GitHub Service Hook for your other packages desandro/imagesloaded and desandro/masonry so perhaps you are not aware of that you should set up GitHub Service Hook for your packages. To set up

  1. Go to your packagist profile and click Show API Token
  2. Copy this secret and go to github repository settings -> Webhooks & services.
  3. Click Add service and from dropdown search packagist
  4. In form you only have to enter your packagist username and copied token and domain you can leave empty.
  5. After you save it open it and click test service

And that's done, there is nothing requiring you or users to login somewhere aswell there is nothing to maintain also no changes required in composer.json, since from there on packgist updates releases automatically any time you create new release on github. So therefore I don't quite understand why not to add it to packagist while it does not affect anything and does not require anything for you to do it.

.gitattributes

Another thing I pointed and added here to the pull request was .gitattributes to exclude dev files from release archives zip and tar.gz created by github. Or do you have some reason include everything in release archives while you do exclude some files in bower.json?

Concluding that we all have different reasons to use different package managers Packagist is used mainly by projects which are built in PHP so back-end stuff however besides it allows you to install also front end components. So I totally understand that most use cases you just use npm or bower, but why exclude some package manager if it does not require from you anything?

Anyhow excellent work keep it up and still hoping to see it on packagis ;) :+1:

desandro commented 6 years ago

I have decided to pass on this Pull Request. Thank you for your contribution!