> Before evaluating I would have to do some research to see how the other > modules, other functions do similar functionality
I've dug into most of tooling by now and I didn't recognize any clear recurring pattern. > I gotta say that this is starting to uncover some other lurking smells that > should be noted and hopefully addressed at some point. [...] I would be happy > to deal with some of these items in separate issues. I've encountered so many of those in the last weeks, it's a wonder I still have a sense of smell :sweat_smile: I just try to tackle these issues one at a time. I don't know if making a list of all of them is going to help, but it definitely won't hurt. I'm just not too eager to make one myself. > Issue with Cordova singletons due to how NPM dependency management works It seems to work reasonably well most of the time, but it's definitely not perfect. Full Dependency Injection would help to solve that, but it's not a common pattern in the JavaScript eco-system AFAICT. Thus my proposal to accept an `EventEmitter` and use it when available. Simple and efficient. > I do not find the layers of abstractions between packages such as > cordova-common, cordova-create/fetch/...,, cordova-serve, cordova-lib, > cordova-cli to be so intuitive. Maybe we can solve this by more clear > documentation of the Cordova tooling architecture. I agree that it's not obvious. Most of it isn't perfect either. It just is what it is. It would definitely be nice to pull more things out of lib. But you just have to take this task one piece at a time. E.g. I would like to pull out the very few things that `cordova-lib` still does during `cordova create` into `cordova-create` and use the latter directly from `cordova-cli`. I've made this when I started working on Cordova tooling:  I was meaning to add that to the `apache/cordova` repo, but I did not get to it yet. [ Full content available at: https://github.com/apache/cordova-create/issues/23 ] This message was relayed via gitbox.apache.org for [email protected]
