Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5786218D3C for ; Mon, 8 Jun 2015 22:03:04 +0000 (UTC) Received: (qmail 33330 invoked by uid 500); 8 Jun 2015 22:03:04 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 33288 invoked by uid 500); 8 Jun 2015 22:03:04 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 33277 invoked by uid 99); 8 Jun 2015 22:03:03 -0000 Received: from git1-us-west.apache.org (HELO git1-us-west.apache.org) (140.211.11.23) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Jun 2015 22:03:03 +0000 Received: by git1-us-west.apache.org (ASF Mail Server at git1-us-west.apache.org, from userid 33) id A7FEEDFF90; Mon, 8 Jun 2015 22:03:03 +0000 (UTC) From: kamrik To: dev@cordova.apache.org Reply-To: dev@cordova.apache.org References: In-Reply-To: Subject: [GitHub] cordova-lib pull request: Implementation for Unified platform API Content-Type: text/plain Message-Id: <20150608220303.A7FEEDFF90@git1-us-west.apache.org> Date: Mon, 8 Jun 2015 22:03:03 +0000 (UTC) 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 infrastructure@apache.org or file a JIRA ticket with INFRA. --- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org For additional commands, e-mail: dev-help@cordova.apache.org