在Symfony2中使用Composer添加CSS或JS庫作為依賴項的正確方法是什么？

Question

在Symfony 2文檔中，它說：

捆綁包不應嵌入用JavaScript，CSS或任何其他語言編寫的第三方庫。

那我該怎么做？ 我想使用Composer安裝Twitter Bootstrap，DataTables和許多其他東西作為依賴項。 但我能想到的唯一方法是創建一個包並嵌入它們。

這樣做的正確方法是什么？

Answer 1

你應該通過Twitter使用Bower 。 它是HTML，CSS和Javascript的包管理器。 它的創建是為了解決您遇到的這個問題。

Answer 2

編輯：截至目前，JS庫的包管理器非常好，如Bower，Jam或Component。

版本控制系統

語義版本控制 - Composer建議使用語義版本控制系統。 它使用XYZ設置，其中X是主要版本，Y是次要版本，Z是補丁版本。 Y和Z應始終向后兼容，而X反映代碼的變化，MIGHT向后兼容。

Embeding

嵌入應該被視為復制並粘貼代碼（和二進制）作為庫的一部分，而不是將其作為第三方（供應商）包/包。 它包括在資源文件夾中包含query.js或將推進代碼復制並粘貼到包內的文件夾中。

為什么不嵌入第三方庫

捆綁包不應嵌入用JavaScript，CSS或任何其他語言編寫的第三方庫。

本聲明來自最佳實踐觀點。 嵌入（如復制/粘貼）任何類型的第三方庫（特別是PHP庫）通常不是一個好主意。 例如，假設BUNDLE A使用LIBRARY FOO v1.4.1，BUNDLE B也使用LIBRARY FOO但使用不同版本v1.5.2。 如果任何BUNDLES（A或B）嵌入了FOO lib，它們可能（很可能會）變得不兼容。 例如，php類和函數不能重新聲明。 當然，任何捆綁包都可以使用變通方法來緩解這個問題，比如命名空間版本的FOO或自動加載規則，但這會增加其他問題，除了肯定會增加內存使用量，因為有兩個版本的同一個東西被解析通過PHP。

如果PHP包不遵循這個最佳實踐，那么出現的錯誤通常很容易被發現（有錯誤：無法重新定位函數blablabla）。 但是，對於Javascript庫，情況並非如此。 您可以重新聲明函數（因為它們是對象屬性）。 因此，如果現在FOO是JS Lib，而BUNDLE A和B將它們嵌入到它們的庫中，當它們被包含在內時，會出現奇怪的問題。 例如，可以重新聲明一個函數，該函數缺少其中一個包的關鍵功能並打破它。

Symfony是一個PHP框架。

它處理PHP庫/包。 Symfony建議要求庫作為依賴而不是嵌入它，因為它使用Composer作為包管理器，它負責下載和加載require包。 據我所知，當2個軟件包/軟件包使用相同的庫時，如果它們具有不同的版本要求，則使用最實際的版本，除非它的向后不兼容。 然后，Composer會報告您必須手動解決的沖突。

但是......沒有辦法正確處理JavaScript庫。 那是因為Composer是PHP庫的包。 您可以通過兩種我能想到的方式來解決這個問題:(可能有更多更好的方法來解決這個問題，我只想到這兩個，將它們作為建議閱讀）

1. 圍繞javascript庫創建一個PHP包裝器並將其包含在內（盡管如果另一個bundle決定做同樣的事情但給包提供不同的名稱，這可能會產生同樣的問題）
2. 通過composer創建一個需要javascript庫作為第三方依賴的bundle。 由於javascript庫可能在其存儲庫中沒有composer.json文件（有時它們作為獨立的縮小文件存在），這可以通過創建自定義編寫器安裝程序 ，分叉javascript存儲庫（例如在gitHub中）來實現一個composer.json，等等...但是，你需要不斷維護和升級所述庫，這可能很麻煩。

你必須記住：

1. 必須公開公開JS和CSS庫，以便客戶端可以訪問它（安全注意事項）
2. Symfony是一個PHP框架，處理服務器端軟件包。 JS / CSS是客戶端。 考慮到這一點，它可以正常工作。
3. symfony背后的主要思想之一（與其他PHP框架一樣）是項目內部和項目之間的代碼可重用性。 純Javascript庫本身可以重用。 它們通常是獨立的。 此外，從服務器端“捆綁”JS庫並沒有真正的好處。 您不需要任何類型的捆綁來實現可重用性。

我的方法

由於編寫器系統非常吸引人，特別是在將bundle / packages / library部署到其他人時，我使用第三方javascript / css庫的方法是創建一個特定於JS / CSS的依賴管理器 ，其他包/ bundle可以依賴它照顧他們的JS / CSS依賴關系而不用擔心這個問題。

我的消化

如果您計划向公眾發布項目，即作為symfony包，您應該仔細計划如何處理這個問題。 如果您的項目是自包含的（個人使用或客戶端，而不是廣泛使用），則由於您（程序員）完全控制您使用的第三方工具並將其包含在項目中，因此其相關性要低得多。 這些只是避免未來問題的最佳實踐“建議”。