在Symfony 2文档中说：
捆绑包不应嵌入用JavaScript、CSS或任何其他语言编写的第三方库。
那我该怎么做呢？我想使用Composer安装Twitter Bootstrap、DataTables和许多其他作为依赖项的东西。但我能想到的唯一方法是创建一个捆绑包并嵌入它们。
正确的方法是什么？
您应该通过Twitter使用Bower。它是一个用于HTML、CSS和Javascript的包管理器。它的创建正是为了解决您所面临的这个问题。
编辑：到目前为止，有非常好的JS库包管理器，如Bower、Jam或Component。
版本控制系统
语义版本控制-Composer建议使用语义版本控制系统。它使用X.Y.Z设置，其中X是主要版本，Y是次要版本，Z是修补程序版本。Y和Z应该始终向后兼容，而X反映了代码中可能会破坏向后兼容性的更改。
嵌入
嵌入应该理解为将代码(和二进制)作为库的一部分进行复制和粘贴，而不是要求将其作为第三方(供应商)包/捆绑包。这就像将query.js包含在资源文件夹中，或者将推进代码复制并粘贴到捆绑包中的文件夹中。
为什么不嵌入第三方libs
捆绑包不应嵌入用JavaScript、CSS或任何其他语言编写的第三方库。
这句话来自最佳实践的观点。嵌入(如复制/粘贴)任何类型的第三方库(尤其是PHP库)通常都不是一个好主意。例如，假设BUNDLE A使用LIBRARY FOO v1.4.1，BUNDLE B也使用LIBRARY FOO，但版本不同。如果任何一个BUNDLES(A或B)嵌入了FOO-lib，它们可能(很可能)变得不兼容。例如，php类和函数不能重新声明。当然，任何捆绑包都可以使用变通方法来缓解这个问题，例如对其版本的FOO或自动加载规则进行名称调整，但这也可能引发其他问题，除了肯定会增加内存使用量之外，因为PHP解析了两个版本的相同内容。
如果PHP包不遵循此最佳实践，则出现的错误通常很容易发现(错误为：无法重新定义blablabla函数)。然而，对于Javascript库，情况并非如此。您可以重新声明函数(因为它们是对象属性)。因此，如果现在FOO是一个JS-Lib，而BUNDLE a和B将它们嵌入到它们的库中，当它们被包含时，可能会出现奇怪的问题。例如，可以重新声明一个函数，该函数缺少其中一个bundle的关键功能并破坏它
Symfony是一个PHP框架
它处理PHP库/捆绑包。Symfony建议需要一个库作为依赖项，而不是嵌入它，因为它使用Composer作为包管理器，负责下载和加载所需的包。据我记忆所及，当两个捆绑包/包使用同一个库时，如果它们有不同的版本要求，则使用最实际的，除非它向后不兼容。然后Composer报告您必须手动解决的冲突。
然而。。。没有办法正确处理javascript库。这是因为Composer是一个PHP库包。你可以用两种方法来解决这个问题我可以想到：(可能有更多最好的方法来处理这个问题，我只是想到了这两种，把它们作为建议来阅读)
- 围绕javascript库创建一个PHP包装并包含它(尽管如果另一个捆绑包决定做同样的事情，但给包起了不同的名称，这可能会产生同样的问题)
- 通过composer创建一个需要javascript库作为第三方依赖项的捆绑包。由于javascript库的存储库中可能没有composer.json文件(有时它们作为一个独立的缩小文件存在)，这可以通过创建一个自定义composer安装程序、分叉javascript存储库(例如在gitHub中)、向其中添加composer.json等来实现。然而，您需要不断维护和升级所述库，这可能是麻烦的
您必须记住：
- JS和CSS库必须公开，这样客户端才能访问它(安全考虑)
- Symfony是一个PHP框架，处理服务器端包。JS/CSS是客户端。考虑到这一点，它才能正常工作
- symfony(与其他PHP框架一样)背后的主要思想之一是项目内部和项目之间的代码可重用性。纯Javascript库本身是可重用的。他们通常是自给自足的。此外，从服务器端"捆绑"JS库并没有真正的好处。您不需要任何类型的捆绑包来实现可重用性
我的方法
由于composer系统非常吸引人，特别是在向其他人部署bundle/packages/libraries时，我使用第三方javascript/css库的方法是创建一个特定于JS/css的依赖关系管理器，其他包/bundle可以依赖该管理器来处理其JS/css依赖关系，而无需担心这一点。
我的建议
如果你计划向公众发布你的项目，即作为一个symfony捆绑包，你应该仔细计划如何实现这一点。如果你的项目是独立的(个人使用或对客户使用，而不是广泛使用)，那么这就没有那么大的相关性，因为你(程序员)完全可以控制你在项目中使用和包含的第三方工具。这些只是要避免的最佳实践"建议"未来的问题。