一個最小的匹配實用程式。
這是npm內部使用的匹配庫。
它的工作原理是將 glob 表達式轉換為 JavaScript RegExp
物件。
// 混合模組,使用 require() 或 importimport { minimatch } from 'minimatch' // 或:const { minimatch } = require('minimatch')minimatch('bar.foo', '*.foo') 載入true! minimatch('bar.foo', '*.bar') // false!minimatch('bar.foo', '*.+(bar|foo)', { debug: true }) // true, 並且吵雜!
支援這些全域功能:
支撐擴張
擴展全域匹配
“Globstar” **
匹配
Posix 字元類,例如[[:alpha:]]
,支援全範圍的 Unicode 字元。例如, [[:alpha:]]
將與'é'
匹配,但[a-zA-Z]
不會。不支援整理符號和設定匹配,因此在ch
被視為單個字元的語言環境中, [[=e=]]
將不匹配'é'
,而[[.ch.]]
將不匹配'ch'
。
看:
man sh
man bash
模式匹配
man 3 fnmatch
man 5 gitignore
請僅在 glob 表達式中使用正斜線。
儘管 Windows 使用/
或 作為其路徑分隔符,但此 glob 實作僅使用/
字元。只能在 glob 表達式中使用正斜線。模式中的反斜線將始終被解釋為轉義字符,而不是路徑分隔符。
請注意,or /
將被解釋為 Windows 上路徑中的路徑分隔符,並將與 glob 表達式中的/
匹配。
所以總是在模式中使用/
。
在 Windows 上,像//?/c:/...
或//ComputerName/Share/...
這樣的 UNC 路徑會被特別處理。
以雙斜線開頭後跟一些非斜線字元的模式將保留其雙斜線。因此,像//*
這樣的模式將匹配//x
,但不匹配/x
。
以//?/<drive letter>:
開頭的模式不會處理?
作為通配符。相反,它將被視為普通字串。
以//?/<drive letter>:/...
開頭的模式將匹配以<drive letter>:/...
開頭的檔案路徑,反之亦然,就好像//?/
不存在一樣。只有當驅動器盤符彼此不區分大小寫的匹配時,才會出現此行為。路徑/模式的其餘部分將區分大小寫進行比較,除非設定了nocase:true
。
請注意,在檔案路徑參數中始終允許使用字元作為路徑分隔符號指定 UNC 路徑,但僅在選項中設定windowsPathsNoEscape: true
時才允許在模式參數中。
透過實例化minimatch.Minimatch
類別來建立 minimatch 物件。
var Minimatch = require('minimatch').Minimatchvar mm = new Minimatch(模式, 選項)
pattern
minimatch 物件表示的原始模式。
options
提供給建構函數的選項。
set
式或字串表達式的二維數組。數組中的每一行對應一個大括號擴展模式。行中的每個項目對應於單一路徑部分。例如,模式{a,b/c}/d
將擴展為一組模式,例如:
[ [ a, d ] , [ b, c, d ] ]
如果模式的一部分沒有任何「魔法」(也就是說,它類似於"foo"
而不是fo*o?
),那麼它將保留為字串而不是轉換為正規表示式。
regexp
由makeRe
方法創建。表達整個模式的單一正規表示式。如果您希望使用類似fnmatch(3)
並啟用FNM_PATH
模式,這非常有用。
negate
如果模式被否定則為真。
comment
如果模式是註解則為真。
empty
如果模式為""
則為真。
makeRe()
如有必要,產生regexp
成員,然後傳回它。如果模式無效,將會傳回false
。
match(fname)
如果檔案名稱與模式匹配,則傳回 true,否則傳回 false。
matchOne(fileArray, patternArray, partial)
採用/
分割的檔案名,並將其與regExpSet
中的單行進行比對。此方法主要供內部使用,但被公開以便需要避免過多檔案系統所呼叫的 glob-walker 可以使用它。
hasMagic()
如果解析的模式包含任何魔術字符,則傳回 true。如果所有比較器部分都是字串文字,則傳回 false。如果在建構函式上設定magicalBraces
選項,那麼它將考慮將原本不神奇的大括號擴展視為魔術。如果未設置,則像a{b,c}d
這樣的模式將傳回false
,因為abd
和acd
都不包含任何特殊的全域字元。
這並不意味著模式字串可以用作文字檔名,因為它可能包含轉義的魔術 glob 字元。例如,模式*
或[*]
不會被認為具有魔力,因為匹配部分解析為文字字串'*'
並且會匹配名為'*'
的路徑,而不是'*'
或'[*]'
。 minimatch.unescape()
方法可用於刪除轉義字元。
所有其他方法都是內部方法,將在必要時呼叫。
主要出口。使用選項根據模式測試路徑。
var isJS = minimatch(file, '*.js', { matchBase: true })
傳回測試其提供的參數的函數,適合與Array.filter
一起使用。例子:
var javascripts = fileList.filter(minimatch.filter('*.js', { matchBase: true }))
對全域模式中的所有魔術字元進行轉義,以便它只匹配文字字串
如果使用windowsPathsNoEscape
選項,則透過用[]
換行來轉義字符,因為字符類中換行的魔術字符只能由該確切字符來滿足。
斜線(以及windowsPathsNoEscape
模式中的反斜線)無法轉義或未轉義。
對可能包含一些轉義字元的全域字串進行取消轉義。
如果使用windowsPathsNoEscape
選項,則刪除方括號轉義符,但不刪除反斜線轉義符。例如,它將字串'[*]'
轉換為*
,但不會將'*'
轉換為'*'
,因為 是windowsPathsNoEscape
模式下的路徑分隔符號。
如果未設定windowsPathsNoEscape
,則會刪除大括號轉義符和反斜線轉義符。
斜線(以及windowsPathsNoEscape
模式中的反斜線)無法轉義或未轉義。
以 fnmatch 或 glob 的風格來匹配檔案清單。如果沒有任何內容匹配,並且設定了 options.nonull,則傳回包含模式本身的清單。
var javascripts = minimatch.match(fileList, '*.js', { matchBase: true })
從模式建立正規表示式物件。
預設情況下,所有選項均為false
。
將大量內容轉儲到 stderr。
不要展開{a,b}
和{1..3}
大括號集。
停用針對多個資料夾名稱的**
匹配。
允許模式匹配以句點開頭的檔案名,即使該模式在該位置沒有明確包含句點。
請注意,預設情況下, a/**/b
不會符合a/.d/b
,除非設定了dot
。
停用“extglob”樣式模式,例如+(a|b)
。
執行不區分大小寫的匹配。
與{nocase: true}
一起使用時,建立不區分大小寫的正規表示式,但保持字串匹配部分不變。在沒有{nocase: true}
的情況下使用時無效
當使用某種其他形式的不區分大小寫的匹配時,或者原始字串表示以其他方式有用時,這很有用。
當minimatch.match
未找到符合項目時,如果設定了此選項,則傳回包含模式本身的清單。如果未設置,如果沒有匹配項,則傳回空列表。
這僅影響Minimatch.hasMagic
方法的結果。
如果模式包含大括號擴展,例如a{b,c}d
,但沒有其他魔術字符,則Minimatch.hasMagic()
方法將預設傳回false
。設定此選項後,對於大括號擴展以及其他魔法全域字符,它將返回true
。
如果設置,則不帶斜線的模式將與路徑的基本名稱(如果包含斜線)進行匹配。例如, a?b
將符合路徑/xyz/123/acb
,但不符合/xyz/acb/123
。
禁止將模式開頭的#
視為註解的行為。
打壓對待領導的行為!
字符為否定。
從否定表達式傳回的結果與未進行否定時相同。 (即命中時為真,未擊中時為假。)
將部分路徑與模式進行比較。只要存在的路徑部分與模式不矛盾,就會被視為匹配。這對於您正在遍歷資料夾結構並且尚未獲得完整路徑,但希望確保您不會沿著永遠無法匹配的路徑進行遍歷的應用程式非常有用。
例如,
minimatch('/a/b', '/a/*/c/d', {partial: true }) // true,可能是 /a/b/c/dminimatch('/a/b', '/ **/d', {partial: true }) // true,可能是/a/b/.../dminimatch('/x/y/z', '/a/**/z', {partial : true }) // false,因為x !== a
僅使用作為路徑分隔符,切勿作為轉義字元。如果設置,則模式中的所有
字元都將替換為
/
。請注意,這使得無法與包含文字 glob 模式字元的路徑進行匹配,但允許與 Windows 平台上使用path.join()
和path.resolve()
構造的模式進行匹配,模仿Windows 上早期版本的(錯誤! )行為。請謹慎使用,並注意有關 Windows 路徑的警告。
由於遺留原因,如果options.allowWindowsEscape
設定為確切值false
也會設定此值。
當模式以 UNC 路徑或磁碟機號碼開頭且處於nocase:true
模式時,請勿將模式的根部分轉換為不區分大小寫的正規表示式,而是將它們保留為字串。
當平台為win32
且設定了nocase:true
時,這是預設值。
預設情況下,多個/
字元(UNC 路徑中的前導//
除外,請參閱上面的“UNC 路徑”)被視為單一/
。
也就是說,像a///b
這樣的模式將匹配檔案路徑a/b
。
設定preserveMultipleSlashes: true
以抑制此行為。
一個數字,指示在解析模式並將其用於匹配之前應對模式進行的最佳化等級。
當設定noglobstar
時,Globstar 部分**
始終轉換為*
,並且多個相鄰**
部分將轉換為單一**
(即a/**/**/b
將被視為a/**/b
,因為這在所有情況下都是等效的)。
0
- 不做進一步的更改。在這種模式下, .
和..
保留在模式中,這意味著它們也必須出現在測試路徑字串中的相同位置。例如,像a/*/../c
這樣的模式將匹配字串a/b/../c
但不符合字串a/c
。
1
-(預設)刪除雙點..
跟隨不是**
, .
的模式部分的情況。 , ..
或空''
。例如,模式./a/b/../*
被轉換為./a/*
,因此它將匹配路徑字串./a/c
,但不匹配路徑字串./a/b/../c
.圖案中的點和空路徑部分將保留。
2
(或更高)- 更積極的優化,適合與文件遍歷案例一起使用:
雖然這些優化提高了文件遍歷用例(例如 glob)的效能(即該模組存在的原因),但在某些情況下,它無法匹配在優化等級 1 或 0 中匹配的文字字串。
具體來說,雖然Minimatch.match()
方法將以相同的方式優化檔案路徑字串,從而產生相同的匹配,但在使用Minimatch.makeRe()
提供的正規表示式進行測試時,它將失敗,除非路徑字串是第一個使用minimatch.levelTwoFileOptimize()
或類似方法進行處理。
刪除雙點..
跟隨不是**
, .
的模式部分的情況。 ,或空''
。刪除空的 和.
模式的一部分,在安全的情況下這樣做(即,除了以/
開頭的模式中的最後一個位置、第一個位置或第二個位置之外的任何位置,因為這可能表示Windows 上的UNC 路徑)。
將包含<pre>/**/../<p>/<rest>
模式轉換為等效的<pre>/{..,**}/<p>/<rest>
,其中<p>
是一個模式除 之外的部分.
, ..
, **
, 或空''
。
重複資料刪除模式中,一個模式中存在**
部分,並且它不是最終路徑部分,並且它們在其他方面是等效的。因此{a/**/b,a/b}
變成a/**/b
,因為**
與空路徑部分相符。
重複資料刪除模式中存在*
部分,以及除**
, 之外的非點模式.
、 ..
或''
位於另一個的相同位置。因此a/{*,x}/b
變成a/*/b
,因為*
可以與x
相符。
當設定為win32
時,這將觸發所有特定於 Windows 的行為(對 UNC 路徑的特殊處理,並將其視為檔案路徑中的分隔符號以進行比較。)
預設為process.platform
的值。
雖然嚴格遵守現有標準是一個有價值的目標,但小型配對和其他實現之間存在一些差異。有些是故意的,有些是不可避免的。
如果模式以!
字符,則它被否定。設定nonegate
標誌來抑制這種行為,並對待leading !
字元正常。如果您希望以負 extglob 模式(如!(a|B)
啟動該模式,這可能是相關的。多種的!
模式開頭的字元將多次否定該模式。
如果模式以#
開頭,則它將被視為註釋,並且不會匹配任何內容。使用#
來匹配行開頭的文字#
,或設定nocomment
標誌來抑制此行為。
預設支援雙星字元**
,除非設定了noglobstar
標誌。這是以 bsdglob 和 bash 4.1 的方式支援的,其中**
僅當它是路徑部分中的唯一內容時才具有特殊意義。也就是說, a/**/b
將符合a/x/y/b
,但a/**b
不會。
如果轉義模式沒有符合項,並且設定了nonull
標誌,則 minimatch.match 將傳回提供的模式,而不是解釋字元轉義。例如, minimatch.match([], "*a?")
將會回傳"*a?"
而不是"*a?"
。這類似於在 bash 中設定nullglob
選項,只不過它不解析轉義模式字元。
如果未停用大括號擴展,則它會在 glob 模式的任何其他解釋之前執行。因此,像+(a|{b),c)}
這樣的模式在 bash 或 zsh 中無效,首先被擴展為+(a|b)
和+(a|c)
的集合,並且這些模式檢查模式的有效性。由於這兩個有效,因此匹配繼續進行。
否定的 extglob 模式的處理盡可能接近 Bash 語義,但在某些情況下,否定的 extglob 很難在 JavaScript 正規表示式中表達。特別是否定模式<start>!(<pattern>*|)*
將在 bash 中匹配任何不以<start><pattern>
開頭的內容。但是, <start>!(<pattern>*)*
將符合以<start><pattern>
開頭的路徑,因為空字串可以與否定部分相符。在此函式庫中, <start>!(<pattern>*|)*
將不符合以<start>
開頭的任何模式,因為在正規表示式與bash 路徑擴展中哪些模式被視為「貪婪」的模式存在差異。這可能是可以修復的,但會帶來一些複雜性和效能成本,而這種權衡似乎不值得追求。
請注意,libc 中的fnmatch(3)
是一個極為簡單的字串比較匹配器,它不會對斜線執行任何特殊操作。該庫設計用於全域搜尋和文件遍歷器,因此它確實使用/
做一些特殊的事情。因此, foo*
將不會匹配此庫中的foo/bar
,即使它在fnmatch(3)
中也是如此。