重寫LESS變量是不好的做法嗎？

我現在在項目上使用Twitter Bootstrap，包括LESS文件和編譯我們已經編寫的一些額外的LESS代碼。重寫LESS變量是不好的做法嗎？

最新版本意味着我們需要重寫一些Bootstrap LESS變量。這裏的一個選擇是維護我們在每個發行版上修補的Bootstrap的修改副本。

但我注意到可以通過在導入語句後重新聲明變量來覆蓋在LESS文件中定義的變量。

例如爲：

@import "twitter-bootstrap/bootstrap.less"; // Restore base font size to pre 2.1.1 defaults @baseFontSize: 13px; // Add some custom LESS code here

這是不好的做法？它是LESS編譯器工作方式的一個人工產物，還是它的一個預期部分？我無法找到這麼多的信息，但我沒有找到以下兩個引用：

因爲在少編譯器，你可以通過它後更改它覆蓋一個變量的「常量」值中的錯誤最初被宣佈。

http://rubysource.com/how-to-customize-twitter-bootstrap%E2%80%99s-design-in-a-rails-app

和

定製通過覆蓋這三個變量的列和排水溝（在grid.less導入後已申報）。

http://semantic.gs/

不太網站本身說，變量是「常量」：

http://lesscss.org/

注意，在更短的變量實際上是「常量」，它們只能是定義一次。

但是然後我看到其他網站使用這種方法..它肯定比維護供應商分支更容易，似乎與less.js工作正常。

想知道這是否是一件壞事要做的任何想法！

來源

2012-10-17 sync

還有一些門票：https：//github.com/cloudhead/less.js/issues/297和https://github.com/cloudhead/less.js/issues/905 –

謝謝，應該看看那裏 - 很有用。雖然我的問題仍然存在，因爲這些問題都沒有任何解決辦法。 – sync

好的！上述問題之一導致了對預期行爲的討論，事實證明，重寫LESS變量很好。

您的聲明將覆蓋CSS中相同範圍中的每一個; LESS也是如此。

https://github.com/cloudhead/less.js/issues/297

就像在CSS，一個範圍內的覆蓋是使用更少的預期方式。

來源

2012-12-11 04:01:56 sync

沒關係！

我通常使用「components」和變量創建一個帶有默認值的較少文件。然後在那之後導入一個具有相同變量但「客戶」值的文件，覆蓋默認值。通過這種方式，我只需要改變一些值，爲每個客戶創建一個新的設計。

這很好，非常有用。

來源

2013-10-03 07:43:13 kurroman

重寫LESS變量是不好的做法嗎？

回答

相關問題