摘要:如何為你的項目添加配置如何為你的項目添加配置現(xiàn)在已經(jīng)是年了,網(wǎng)上許多教程和分享帖都已經(jīng)過期,照著他們的步驟來會踩一些坑,如已經(jīng)不再維護,以及之后文件只剩下部分等。如有疑問或授權(quán)協(xié)商請與我聯(lián)系。
現(xiàn)在已經(jīng)是 9102 年了,網(wǎng)上許多教程和分享帖都已經(jīng)過期,照著他們的步驟來會踩一些坑,如 stylelint-processor-html
已經(jīng)不再維護,以及 --fix
之后 .vue
文件只剩下 部分等。我在踩完坑跑通出滿意的效果后,維護一份新的指引,以備后續(xù)項目使用,順便分享一下。
這個問題有兩層含義,一是為什么要使用這個樣式代碼風格檢查工具,二是與其他工具相比,為什么選擇 stylelint 而不是其他如 stylefmt 等。
對于第一個問題,相信很多小伙伴都會被歷史遺留的,或多人協(xié)同開發(fā)寫下的風格不一的樣式代碼困擾過,最基本的就是換行、縮進和空格之爭,大家對此應(yīng)該都不陌生。特別是有時候你可能會遇上如下祖?zhèn)鞔a:
#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-
前綴,但是項目中已經(jīng)支持 autoprefixer
;當然代碼風格因人而異,所以才需要團隊統(tǒng)一。在一些早期缺乏完善的代碼評審等制度的項目中,很容易由于程序員的偷懶圖方便或在一時的緊急粗糙趕工中積累下一坨對團隊其他成員不太友好、可閱讀性低、較難維護的 css 。
至于第二個問題,選擇 stylelint 的原因也很簡單,它是當前所有同類工具中使用人數(shù)最多的,社區(qū)較為活躍,仍在持續(xù)維護。而且正如這個 issue 中提到,當下很多大廠都在使用,如 github 的 primer 體系就定制了一套自己的規(guī)則 stylelint-config-primer
。
至于 stylefmt 也曾經(jīng)被推薦與 stylelint 搭配組合,不少博文都有提到。但是官方已經(jīng)不推薦繼續(xù)使用,直接用 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 的原因則是它希望提供一套官方自己認可的統(tǒng)一風格規(guī)范,而不僅僅是個 linter 或者 formatter ,可配置項很少,定制自由度較低,不適合想要自己搞事情的團隊,更適合個人開發(fā)者去使用。
其實官方的 User guide 已經(jīng)很全面,與 eslint 是非常相似的。
安裝 stylelint
npm i -D stylelint stylelint-config-stand
后者 stylelint-config-stand
不是必需的,也可以自己根據(jù)文檔從零開始配置規(guī)則,或者用第三方如 github 的規(guī)則 stylelint-config-primer
。
安裝適配預(yù)處理語法的插件
以 sass 為例:
npm i -D stylelint-scss
不過 stylus 目前沒有發(fā)現(xiàn)可用性高的相關(guān)插件,也導(dǎo)致 stylelint 不能解析 stylus 語法。
安裝 webpack 插件
npm i -D stylelint-webpack-plugin
stylelint 搜索目錄和文件使用的是 glob 規(guī)則:
npx stylelint --cache **/*.{html,vue,css,sass,scss} --fix
--cache
選項可以指定使用緩存,默認生成的 .stylelintcache
文件放置于執(zhí)行目錄中, --fix
選項可以指定 stylelint 自動修復(fù)不符合可修復(fù)規(guī)則的代碼,其他更多選項可以參考官方文檔。
但需要注意有一個問題,在沒有配置使用 stylelint-scss
之類的插件前, stylelint 是不能直接解析 vue 文件、 html 文件等的,會報出一堆錯誤:
1:1 ? Unknown word CssSyntaxError
我們可以用內(nèi)置的自定義語法 postcss-html
來解析(不需安裝):
npx stylelint **/*.{html,vue} --custom-syntax postcss-html
也可以用內(nèi)置的 scss 語法支持來解析 css 文件:
npx stylelint **/*.{css,sass,scss} --syntax scss
在 scripts 中加一下就好了,對于 9102 年的前端程序員應(yīng)該都是基本操作:
// 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"
兩種,用于定義全局默認的報錯等級。但是它沒有相應(yīng)的 cli 選項,實際上不太好用——比如你想 stylelint-webpack-plugin
只是警告,而 git-hooks 則是直接報錯不允許提交的時候。文檔上關(guān)于如何對規(guī)則多帶帶配置錯誤等級有一句話提到了如何去控制:
Different reporters may use these severity levels in different way, e.g. display them differently, or exit the process differently.
但是卻沒有在其他地方或者 Developer guide 中找到任何與 reporters 有關(guān)的信息,有可能是需要自己寫一個 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
來簡單實現(xiàn),但是我們可能期望在一些遺留的老舊代碼上先暫時不啟用 stylelint ,等后續(xù)再慢慢放開,這樣的話需要配置的文件路徑就有點多了。為了方便我們可以再編寫一個 .stylelintignore
文件,它的語法是跟 .gitignore
和 .eslintignore
一樣的:
# .stylelintignore
# 舊的不需打包的樣式庫
*.min.css
# 其他類型文件
*.js
*.jpg
*.woff
# 測試和打包目錄
/test/
/dist/
# 通過反取忽略目錄
/src/component/*
!/src/component/CompA
!/src/component/CompB
# 這樣的效果是除 CompA 和 CompB 外其他目錄都會被忽略
更多可以參考 node-ignore
。
如果項目中已經(jīng)在用 husky 的 pre-commit
鉤子來運行 eslint ,現(xiàn)在要加 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
會不會有沖突?暫時未在網(wǎng)上見相關(guān)討論,我自己運行也沒有任何問題,如果實在擔心的話,可以將 glob 匹配分開定義。
也是跟 eslint 類似的,我們可以通過 stylelint-disable
注釋來局部禁用某一項規(guī)則。
但是隨之而來的是一個常見錯誤:你在文件頭部忽略了對瀏覽器前綴的提示,卻在另一個遙遠的地方由于暫時性允許同名屬性,通過 /* stylelint-enable */
把之前所有忽略的規(guī)則都重新開啟了。所以一定要注意,只 enable 對應(yīng)的規(guī)則,形成呼應(yīng):
解析 .vue
文件(單文件組件)時請勿使用 processors
網(wǎng)上一些過時的教程包括 github 上的討論都推薦使用 stylelint-processor-html
或者 @mapbox/stylelint-processor-arbitrary-tags
來解析 html 或 vue 中的 css ,這本身并沒有什么問題,但是這個插件有個 bug ,當指定 stylelint 的 --fix
后將會把 vue 文件中 以外的部分刪掉。
我們使用自定義語法 postcss-html
或者保留 stylelint-scss
插件就足夠了。
一些規(guī)則在跑 --fix
選項時是有 bug 的
比如 declaration-block-semicolon-newline-after
設(shè)置 "always"
時,不允許多條 css 規(guī)則寫在一行,但自動修復(fù)后可能會出現(xiàn)縮進不正確:
修復(fù)后(示例,之前配置時沒嘗試去找必現(xiàn)路徑):
如果你也出現(xiàn)這種情況,可以再指定 indentation
規(guī)則的基準縮進( baseIndentLevel
):
module.exports = {
...
rules: {
...
'indentation': [2, {
'baseIndentLevel': 1,
}],
'declaration-block-semicolon-newline-after': 'always'
}
};
本文基于 知識共享署名-非商業(yè)性使用-相同方式共享 4.0 國際許可協(xié)議 發(fā)布,歡迎引用、轉(zhuǎn)載或演繹,但是必須保留本文的署名 BlackStorm 以及本文鏈接 http://www.cnblogs.com/BlackStorm/p/add-stylelint-to-your-vue-project.html ,且未經(jīng)許可不能用于商業(yè)目的。如有疑問或授權(quán)協(xié)商請與我聯(lián)系。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://m.hztianpu.com/yun/1365.html
摘要:為此我們需要安裝這個是用于提交代碼的鉤子函數(shù)安裝完之后,我們就需要在增加運行鉤子函數(shù)。等鉤子函數(shù)這樣就簡單的成功對代碼進行效驗了,當然這邊更進一步的可以使用這個可以將取得所有被提交的文件依次執(zhí)行寫好的任務(wù)。 一個項目是會有多個成員來開發(fā)的,因此統(tǒng)一開發(fā)規(guī)范是很有必要的,不然每個人都有自己的風格,同步之后代碼都會報錯。我這邊是用Vscode編譯器的。 首先用vue-cli3.0創(chuàng)建一個工...
摘要:從到再到搭建編寫構(gòu)建一個前端項目選擇現(xiàn)成的項目模板還是自己搭建項目骨架搭建一個前端項目的方式有兩種選擇現(xiàn)成的項目模板自己搭建項目骨架。使用版本控制系統(tǒng)管理源代碼項目搭建好后,需要一個版本控制系統(tǒng)來管理源代碼。 從 0 到 1 再到 100, 搭建、編寫、構(gòu)建一個前端項目 1. 選擇現(xiàn)成的項目模板還是自己搭建項目骨架 搭建一個前端項目的方式有兩種:選擇現(xiàn)成的項目模板、自己搭建項目骨架。 ...
摘要:從到再到搭建編寫構(gòu)建一個前端項目選擇現(xiàn)成的項目模板還是自己搭建項目骨架搭建一個前端項目的方式有兩種選擇現(xiàn)成的項目模板自己搭建項目骨架。使用版本控制系統(tǒng)管理源代碼項目搭建好后,需要一個版本控制系統(tǒng)來管理源代碼。 從 0 到 1 再到 100, 搭建、編寫、構(gòu)建一個前端項目 1. 選擇現(xiàn)成的項目模板還是自己搭建項目骨架 搭建一個前端項目的方式有兩種:選擇現(xiàn)成的項目模板、自己搭建項目骨架。 ...
摘要:從到再到搭建編寫構(gòu)建一個前端項目選擇現(xiàn)成的項目模板還是自己搭建項目骨架搭建一個前端項目的方式有兩種選擇現(xiàn)成的項目模板自己搭建項目骨架。使用版本控制系統(tǒng)管理源代碼項目搭建好后,需要一個版本控制系統(tǒng)來管理源代碼。 從 0 到 1 再到 100, 搭建、編寫、構(gòu)建一個前端項目 1. 選擇現(xiàn)成的項目模板還是自己搭建項目骨架 搭建一個前端項目的方式有兩種:選擇現(xiàn)成的項目模板、自己搭建項目骨架。 ...
摘要:代碼質(zhì)量這個術(shù)語對于程序員來說并不陌生。在本文中,我們將探討我們?nèi)绾文軌蚶脦椭覀?,保持我們的代碼質(zhì)量更高。怎樣使用在這篇文章中,我們重點介紹幾個插件,可以幫助我們提高代碼質(zhì)量。使用相當簡單的。這兩個插件可用于代碼分析。 代碼質(zhì)量這個術(shù)語對于程序員來說并不陌生。畢竟,每個開發(fā)人員都知道,代碼只是能工作是不夠的。它還應(yīng)該具備其他要素:它應(yīng)該是可讀的,良好的格式和一致性。它也應(yīng)該符合一些...
閱讀 847·2023-04-25 19:43
閱讀 4120·2021-11-30 14:52
閱讀 3931·2021-11-30 14:52
閱讀 4027·2021-11-29 11:00
閱讀 3922·2021-11-29 11:00
閱讀 4039·2021-11-29 11:00
閱讀 3771·2021-11-29 11:00
閱讀 6609·2021-11-29 11:00