摘要:如何為你的項目添加配置如何為你的項目添加配置現在已經是年了,網上許多教程和分享帖都已經過期,照著他們的步驟來會踩一些坑,如已經不再維護,以及之后文件只剩下部分等。如有疑問或授權協商請與我聯系。
現在已經是 9102 年了,網上許多教程和分享帖都已經過期,照著他們的步驟來會踩一些坑,如 stylelint-processor-html
已經不再維護,以及 --fix
之后 .vue
文件只剩下 部分等。我在踩完坑跑通出滿意的效果后,維護一份新的指引,以備后續項目使用,順便分享一下。
這個問題有兩層含義,一是為什么要使用這個樣式代碼風格檢查工具,二是與其他工具相比,為什么選擇 stylelint 而不是其他如 stylefmt 等。
對于第一個問題,相信很多小伙伴都會被歷史遺留的,或多人協同開發寫下的風格不一的樣式代碼困擾過,最基本的就是換行、縮進和空格之爭,大家對此應該都不陌生。特別是有時候你可能會遇上如下祖傳代碼:
#idA .classB,.classC{position:absolute;top: 0;left:0; display:-webkit-flex;display: flex;width:100%;background:url(../pic.png) no-repeat;-webkit-background-size:contain;background-size:contain }
這段代碼從我個人風格來看存在不少問題:
-webkit-
前綴,但是項目中已經支持 autoprefixer
;當然代碼風格因人而異,所以才需要團隊統一。在一些早期缺乏完善的代碼評審等制度的項目中,很容易由于程序員的偷懶圖方便或在一時的緊急粗糙趕工中積累下一坨對團隊其他成員不太友好、可閱讀性低、較難維護的 css 。
至于第二個問題,選擇 stylelint 的原因也很簡單,它是當前所有同類工具中使用人數最多的,社區較為活躍,仍在持續維護。而且正如這個 issue 中提到,當下很多大廠都在使用,如 github 的 primer 體系就定制了一套自己的規則 stylelint-config-primer
。
至于 stylefmt 也曾經被推薦與 stylelint 搭配組合,不少博文都有提到。但是官方已經不推薦繼續使用,直接用 stylelint 的 --fix
選項即可。
NOTICE: Consider other tools before adopting stylefmt
If you are using stylefmt with stylelint configuration to format according to its rules, you can now use stylelints --fix option (from v7.11.0) to autofix.Another on the other hand, prettier supports to format not only JavaScript but also CSS, SCSS and Less code.
而沒有考慮 prettier 的原因則是它希望提供一套官方自己認可的統一風格規范,而不僅僅是個 linter 或者 formatter ,可配置項很少,定制自由度較低,不適合想要自己搞事情的團隊,更適合個人開發者去使用。
其實官方的 User guide 已經很全面,與 eslint 是非常相似的。
安裝 stylelint
npm i -D stylelint stylelint-config-stand
后者 stylelint-config-stand
不是必需的,也可以自己根據文檔從零開始配置規則,或者用第三方如 github 的規則 stylelint-config-primer
。
安裝適配預處理語法的插件
以 sass 為例:
npm i -D stylelint-scss
不過 stylus 目前沒有發現可用性高的相關插件,也導致 stylelint 不能解析 stylus 語法。
安裝 webpack 插件
npm i -D stylelint-webpack-plugin
stylelint 搜索目錄和文件使用的是 glob 規則:
npx stylelint --cache **/*.{html,vue,css,sass,scss} --fix
--cache
選項可以指定使用緩存,默認生成的 .stylelintcache
文件放置于執行目錄中, --fix
選項可以指定 stylelint 自動修復不符合可修復規則的代碼,其他更多選項可以參考官方文檔。
但需要注意有一個問題,在沒有配置使用 stylelint-scss
之類的插件前, stylelint 是不能直接解析 vue 文件、 html 文件等的,會報出一堆錯誤:
1:1 ? Unknown word CssSyntaxError
我們可以用內置的自定義語法 postcss-html
來解析(不需安裝):
npx stylelint **/*.{html,vue} --custom-syntax postcss-html
也可以用內置的 scss 語法支持來解析 css 文件:
npx stylelint **/*.{css,sass,scss} --syntax scss
在 scripts 中加一下就好了,對于 9102 年的前端程序員應該都是基本操作:
// package.json
{
"scripts": {
"lint:style": "stylelint **/*.{html,vue} --custom-syntax postcss-html",
"lint:css": "stylelint **/*.{css,sass,scss} --syntax scss"
}
}
或者(配置了 stylelint-scss
插件后):
{
"scripts": {
"lint:css": "stylelint **/*.{html,vue,css,sass,scss}"
}
}
然后可以手動在命令行運行:
npm run lint:css
npm run lint:css -- --fix
npm run lint:css -- --cache --fix
// webpack.conf.js
const StyleLintPlugin = require('stylelint-webpack-plugin');
module.exports = {
...
'plugins': [
...
new StyleLintPlugin({
'files': ['**/*.{html,vue,css,sass,scss}'],
'fix': false,
'cache': true,
'emitErrors': true,
'failOnError': false
})
]
};
stylelint 支持的所有命令行選項都可以在初始化插件時傳遞 options 來指定,包括上文提到的 --syntax
等。更多可以參考 stylelint-webpack-plugin
官方文檔。
stylelint 支持 cosmiconfig 的配置方式,按如下順序查找配置對象:
package.json
中的 stylelint
屬性.stylelintrc
文件(可帶后綴)stylelint.config.js
文件它的配置也非常簡單,只有 rules
、 extends
、 plugins
、 processors
、 ignoreFiles
和 defaultSeverity
。
其中 defaultSeverity
只支持 "warning"
和 "error"
兩種,用于定義全局默認的報錯等級。但是它沒有相應的 cli 選項,實際上不太好用——比如你想 stylelint-webpack-plugin
只是警告,而 git-hooks 則是直接報錯不允許提交的時候。文檔上關于如何對規則多帶帶配置錯誤等級有一句話提到了如何去控制:
Different reporters may use these severity levels in different way, e.g. display them differently, or exit the process differently.
但是卻沒有在其他地方或者 Developer guide 中找到任何與 reporters 有關的信息,有可能是需要自己寫一個 formatter 。
一個簡單的配置示例:
// stylelint.config.js
module.exports = {
'defaultSeverity': 'error',
'extends': [ 'stylelint-config-standard' ],
'plugins': [ 'stylelint-scss' ],
'rules': {
// 不要使用已被 autoprefixer 支持的瀏覽器前綴
'media-feature-name-no-vendor-prefix': true,
'at-rule-no-vendor-prefix': true,
'selector-no-vendor-prefix': true,
'property-no-vendor-prefix': true,
'value-no-vendor-prefix': true
}
};
由于可以用 stylelint-scss
去解析文件中的 scss 代碼,我們暫時不需要使用官方列出的任何 processors
。
雖然可以通過配置 ignoreFiles
來簡單實現,但是我們可能期望在一些遺留的老舊代碼上先暫時不啟用 stylelint ,等后續再慢慢放開,這樣的話需要配置的文件路徑就有點多了。為了方便我們可以再編寫一個 .stylelintignore
文件,它的語法是跟 .gitignore
和 .eslintignore
一樣的:
# .stylelintignore
# 舊的不需打包的樣式庫
*.min.css
# 其他類型文件
*.js
*.jpg
*.woff
# 測試和打包目錄
/test/
/dist/
# 通過反取忽略目錄
/src/component/*
!/src/component/CompA
!/src/component/CompB
# 這樣的效果是除 CompA 和 CompB 外其他目錄都會被忽略
更多可以參考 node-ignore
。
如果項目中已經在用 husky 的 pre-commit
鉤子來運行 eslint ,現在要加 stylelint 其實很簡單:
// package.json
{
...
"lint-staged": {
"*.{vue,js}": [
"eslint --fix",
"git add"
],
"*.{html,vue,css,sass,scss}": [
"stylelint --fix",
"git add",
]
},
"husky": {
"hooks": {
"pre-commit": "lint-staged",
}
}
}
唯一需要注意的是, lint-staged 默認是并行運行的,同時對 .vue
文件做 git add
會不會有沖突?暫時未在網上見相關討論,我自己運行也沒有任何問題,如果實在擔心的話,可以將 glob 匹配分開定義。
也是跟 eslint 類似的,我們可以通過 stylelint-disable
注釋來局部禁用某一項規則。
但是隨之而來的是一個常見錯誤:你在文件頭部忽略了對瀏覽器前綴的提示,卻在另一個遙遠的地方由于暫時性允許同名屬性,通過 /* stylelint-enable */
把之前所有忽略的規則都重新開啟了。所以一定要注意,只 enable 對應的規則,形成呼應:
解析 .vue
文件(單文件組件)時請勿使用 processors
網上一些過時的教程包括 github 上的討論都推薦使用 stylelint-processor-html
或者 @mapbox/stylelint-processor-arbitrary-tags
來解析 html 或 vue 中的 css ,這本身并沒有什么問題,但是這個插件有個 bug ,當指定 stylelint 的 --fix
后將會把 vue 文件中 以外的部分刪掉。
我們使用自定義語法 postcss-html
或者保留 stylelint-scss
插件就足夠了。
一些規則在跑 --fix
選項時是有 bug 的
比如 declaration-block-semicolon-newline-after
設置 "always"
時,不允許多條 css 規則寫在一行,但自動修復后可能會出現縮進不正確:
修復后(示例,之前配置時沒嘗試去找必現路徑):
如果你也出現這種情況,可以再指定 indentation
規則的基準縮進( baseIndentLevel
):
module.exports = {
...
rules: {
...
'indentation': [2, {
'baseIndentLevel': 1,
}],
'declaration-block-semicolon-newline-after': 'always'
}
};
本文基于 知識共享署名-非商業性使用-相同方式共享 4.0 國際許可協議 發布,歡迎引用、轉載或演繹,但是必須保留本文的署名 BlackStorm 以及本文鏈接 http://www.cnblogs.com/BlackStorm/p/add-stylelint-to-your-vue-project.html ,且未經許可不能用于商業目的。如有疑問或授權協商請與我聯系。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/1365.html
摘要:為此我們需要安裝這個是用于提交代碼的鉤子函數安裝完之后,我們就需要在增加運行鉤子函數。等鉤子函數這樣就簡單的成功對代碼進行效驗了,當然這邊更進一步的可以使用這個可以將取得所有被提交的文件依次執行寫好的任務。 一個項目是會有多個成員來開發的,因此統一開發規范是很有必要的,不然每個人都有自己的風格,同步之后代碼都會報錯。我這邊是用Vscode編譯器的。 首先用vue-cli3.0創建一個工...
摘要:從到再到搭建編寫構建一個前端項目選擇現成的項目模板還是自己搭建項目骨架搭建一個前端項目的方式有兩種選擇現成的項目模板自己搭建項目骨架。使用版本控制系統管理源代碼項目搭建好后,需要一個版本控制系統來管理源代碼。 從 0 到 1 再到 100, 搭建、編寫、構建一個前端項目 1. 選擇現成的項目模板還是自己搭建項目骨架 搭建一個前端項目的方式有兩種:選擇現成的項目模板、自己搭建項目骨架。 ...
摘要:從到再到搭建編寫構建一個前端項目選擇現成的項目模板還是自己搭建項目骨架搭建一個前端項目的方式有兩種選擇現成的項目模板自己搭建項目骨架。使用版本控制系統管理源代碼項目搭建好后,需要一個版本控制系統來管理源代碼。 從 0 到 1 再到 100, 搭建、編寫、構建一個前端項目 1. 選擇現成的項目模板還是自己搭建項目骨架 搭建一個前端項目的方式有兩種:選擇現成的項目模板、自己搭建項目骨架。 ...
摘要:從到再到搭建編寫構建一個前端項目選擇現成的項目模板還是自己搭建項目骨架搭建一個前端項目的方式有兩種選擇現成的項目模板自己搭建項目骨架。使用版本控制系統管理源代碼項目搭建好后,需要一個版本控制系統來管理源代碼。 從 0 到 1 再到 100, 搭建、編寫、構建一個前端項目 1. 選擇現成的項目模板還是自己搭建項目骨架 搭建一個前端項目的方式有兩種:選擇現成的項目模板、自己搭建項目骨架。 ...
摘要:代碼質量這個術語對于程序員來說并不陌生。在本文中,我們將探討我們如何能夠利用幫助我們,保持我們的代碼質量更高。怎樣使用在這篇文章中,我們重點介紹幾個插件,可以幫助我們提高代碼質量。使用相當簡單的。這兩個插件可用于代碼分析。 代碼質量這個術語對于程序員來說并不陌生。畢竟,每個開發人員都知道,代碼只是能工作是不夠的。它還應該具備其他要素:它應該是可讀的,良好的格式和一致性。它也應該符合一些...
閱讀 713·2023-04-25 19:43
閱讀 3910·2021-11-30 14:52
閱讀 3784·2021-11-30 14:52
閱讀 3852·2021-11-29 11:00
閱讀 3783·2021-11-29 11:00
閱讀 3869·2021-11-29 11:00
閱讀 3558·2021-11-29 11:00
閱讀 6105·2021-11-29 11:00