Github user kamrik commented on the pull request:
https://github.com/apache/cordova-lib/pull/235#issuecomment-110155367
I don't have strong opinion here, but a bit more inclined towards
dependency injection. For some modules like ConfigParser having different
versions imported by different platforms can get very frustrating. Even when
cordova is used without thc CLI, large parts of cordova-lib would still be
needed, whether required()'d directly by the user or implicitly via
cordova-android. So as an extreme option we can dependency-inject the entire
cordova-lib (properly exposing the relevant classes). Somewhat more elegantly,
we could construct a module inside cordova-lib with just the needed classes and
inject it when instantiating cordova-android API. It might be useful to later
split out this module as a separate npm package (or several packages), but for
time being they could still stay part of the lib.
Superspawn is definitely a candidate for being a totally separate module.
But modules like PluginInfo and ConfigParser are very unlikely to be used
separately from each other. Maybe in the long run they should live in some new
package named like "cordova-core", or we could move the CLI specific stuff out
of cordova-lib and into cordova-cli, then the lib would become that core.
That said, I'm fine with the approach you suggested.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
