You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been using a fork of this module in a framework-only project for some months without issue. I'd like to remove the forked module from my codebase, but if I install this module into my framework-only project with Composer, I get a bunch of CMS-related packages and my test suite and functionality obviously falls to bits.
As far as I can tell looking at the code, there's no need for the silverstripe/cms package at all. It's referenced in composer.json and phpunit.xml.dist (the latter can be replaced by a framework-only bootstrap of course). So is there any other reason why a CMS dependency is used? Could the module get away with silverstripe/framework or silverstripe/admin in its place?
The text was updated successfully, but these errors were encountered:
I've been using a fork of this module in a framework-only project for some months without issue. I'd like to remove the forked module from my codebase, but if I install this module into my framework-only project with Composer, I get a bunch of CMS-related packages and my test suite and functionality obviously falls to bits.
As far as I can tell looking at the code, there's no need for the
silverstripe/cms
package at all. It's referenced incomposer.json
andphpunit.xml.dist
(the latter can be replaced by a framework-only bootstrap of course). So is there any other reason why a CMS dependency is used? Could the module get away withsilverstripe/framework
orsilverstripe/admin
in its place?The text was updated successfully, but these errors were encountered: