20

在Symfony 2 文档中它说：

捆绑软件不应嵌入以 JavaScript、CSS 或任何其他语言编写的第三方库。

那我该怎么做呢？我想使用 Composer 安装 Twitter Bootstrap、DataTables 和许多其他东西作为依赖项。但我能想到的唯一方法是创建一个包并嵌入它们。

这样做的正确方法是什么？

4

2 回答 2

14

你应该使用Twitter 的Bower。它是 HTML、CSS 和 Javascript 的包管理器。它的创建是为了解决您遇到的这个问题。

于 2013-01-19T19:23:39.770 回答
6

编辑：截至目前，有非常好的 JS 库包管理器，例如 Bower、Jam 或 Component。

版本控制系统

语义版本控制- Composer 建议使用语义版本控制系统。它使用 XYZ 设置，其中 X 是主要版本，Y 是次要版本，Z 是补丁版本。Y 和 Z 应该始终向后兼容，而 X 反映可能破坏向后兼容性的代码更改。

嵌入

嵌入应该被理解为复制和粘贴代码（和二进制）作为库的一部分，而不是要求它作为第三方（供应商）包/包。就像在资源文件夹中包含 query.js 或将推进代码复制并粘贴到包内的文件夹中一样。

为什么不嵌入 3rd 方库

捆绑软件不应嵌入以 JavaScript、CSS 或任何其他语言编写的第三方库。

该声明来自最佳实践的观点。嵌入（如复制/粘贴）任何类型的第三方库（尤其是 PHP 库）通常不是一个好主意。例如，假设 BUNDLE A 使用 LIBRARY FOO v1.4.1，而 BUNDLE B 也使用 LIBRARY FOO，但版本不同 v1.5.2。如果任何 BUNDLES（A 或 B）嵌入 FOO lib，它们可能（很可能会）变得不兼容。例如，不能重新声明 php 类和函数。当然，任何捆绑软件都可以使用变通方法来缓解这个问题，例如为其 FOO 版本命名空间或自动加载规则，但这可能会引发其他问题，除了肯定会增加内存使用量，因为解析了相同内容的 2 个版本通过 PHP。

如果 PHP 包没有遵循这个最佳实践，那么出现的错误通常很容易发现（错误：无法重新定义函数 blablabla）。但是，对于 Javascript 库，情况并非如此。您可以重新声明函数（因为它们是对象属性）。所以如果现在 FOO 是一个 JS Lib，而 BUNDLE A 和 B 将它们嵌入到它们的库中，当它们被包含时，就会出现奇怪的问题。例如，可以重新声明一个函数，该函数缺少其中一个包的关键功能并破坏它。

Symfony 是一个 PHP 框架。

它处理 PHP 库/包。Symfony 建议将一个库作为依赖项而不是嵌入它，因为它使用 Composer 作为包管理器，负责下载和加载所需的包。据我记得，当 2 个包/包使用同一个库时，如果它们有不同的版本要求，则使用最实际的，除非它向后不兼容。Composer 然后报告您必须手动解决的冲突。

但是...没有办法正确处理 javascript 库。那是因为 Composer 是 PHP 库的一个包。您可以通过我能想到的两种方式来解决这个问题：（可能有更多和最好的方法来处理这个问题，我只是想到了这两个，将它们作为建议阅读）

  1. 围绕 javascript 库创建一个 PHP 包装器并包含它（尽管如果另一个包决定做同样的事情但给包一个不同的名称，这可能会产生同样的问题）
  2. 通过 composer 创建一个需要 javascript 库作为第三方依赖项的包。由于 javascript 库的存储库中可能没有 composer.json 文件（有时它们作为独立的缩小文件存在），这可以通过创建自定义 composer installer来完成，分叉 javascript 存储库（例如在 gitHub 中）添加一个composer.json，等等......但是，您将需要不断维护和升级上述库，这可能很麻烦。

您必须记住：

  1. JS 和 CSS 库必须公开，以便客户端可以访问它（安全考虑）
  2. Symfony 是一个 PHP 框架，处理服务器端包。JS/CSS 是客户端。考虑到这一点，它才能正常工作。
  3. symfony 背后的主要思想之一（与其他 PHP 框架一样）是项目内部和项目之间的代码可重用性。纯 Javascript 库本身是可重用的。它们通常是独立的。此外，从服务器端“捆绑”一个 JS 库并没有真正的好处。您不需要任何类型的捆绑软件来实现可重用性。

我的方法

由于作曲家系统非常吸引人，特别是在将包/包/库部署给其他人时，我使用第三方 javascript/css 库的方法是创建一个特定于 JS/CSS 的依赖管理器，其他包/包可以依赖它照顾他们的 JS/CSS 依赖，而不用担心这个。

我的建议

如果你打算向公众发布你的项目，即作为一个 symfony 包，你应该仔细计划如何处理这个问题。如果您的项目是自包含的（个人使用或客户使用，而不是广泛使用），那么这与您（程序员）的相关性要低得多，因为您（程序员）可以完全控制您使用的第三方工具并包含在您的项目中。这些只是避免将来出现问题的最佳实践“建议”。

于 2012-07-24T02:58:41.133 回答