In v4.0.0-beta.1, Composer support was dropped temporarily. (composer.json was deleted ... not sure if this prevents future releases for composer. probably does)
The reason I did this is because the distribution mechanism for fullcalendar packages has changed. Now, fullcalendar is broken up into a number of plugins, each of which is registered independently with a package manager like NPM. The fullcalendar repo still hosts the source code of all these plugins, and the dist directory gets populated for each release, and gets tagged, but it's unclear if/how we should break up each plugin package for composer in the same way we do for NPM.
I started thinking about it and realized I didn't know enough about how Composer works.
Instead of implementing something in fullcalendar's build/release system, what do people think about Asset Packagist? https://asset-packagist.org/
If we register fullcalendar's core and all plugins with that system, will that suffice?
Has anyone been using Composer for JS packages in the last couple of years?
I think that NPM/Yarn has taken over the JS package handling for the majority of developers.
Only old projects would still use Composer for this. And they aren't that likely to update their dependencies without major refactoring and moving over to NPM/Yarn anyway.
TL;DR: I vote for removing Composer support.
We'll keep it removed
Most helpful comment
Has anyone been using Composer for JS packages in the last couple of years?
I think that NPM/Yarn has taken over the JS package handling for the majority of developers.
Only old projects would still use Composer for this. And they aren't that likely to update their dependencies without major refactoring and moving over to NPM/Yarn anyway.
TL;DR: I vote for removing Composer support.