ansi-regex
Advanced tools
Comparing version 2.0.0 to 2.1.1
'use strict'; | ||
module.exports = function () { | ||
return /[\u001b\u009b][[()#;?]*(?:[0-9]{1,4}(?:;[0-9]{0,4})*)?[0-9A-ORZcf-nqry=><]/g; | ||
return /[\u001b\u009b][[()#;?]*(?:[0-9]{1,4}(?:;[0-9]{0,4})*)?[0-9A-PRZcf-nqry=><]/g; | ||
}; |
{ | ||
"name": "ansi-regex", | ||
"version": "2.0.0", | ||
"version": "2.1.1", | ||
"description": "Regular expression for matching ANSI escape codes", | ||
"license": "MIT", | ||
"repository": "sindresorhus/ansi-regex", | ||
"repository": "chalk/ansi-regex", | ||
"author": { | ||
@@ -14,3 +14,4 @@ "name": "Sindre Sorhus", | ||
"Sindre Sorhus <sindresorhus@gmail.com> (sindresorhus.com)", | ||
"Joshua Appelman <jappelman@xebia.com> (jbnicolai.com)" | ||
"Joshua Appelman <jappelman@xebia.com> (jbnicolai.com)", | ||
"JD Ballard <i.am.qix@gmail.com> (github.com/qix-)" | ||
], | ||
@@ -21,4 +22,4 @@ "engines": { | ||
"scripts": { | ||
"test": "mocha test/test.js", | ||
"view-supported": "node test/viewCodes.js" | ||
"test": "xo && ava --verbose", | ||
"view-supported": "node fixtures/view-codes.js" | ||
}, | ||
@@ -56,4 +57,11 @@ "files": [ | ||
"devDependencies": { | ||
"mocha": "*" | ||
"ava": "0.17.0", | ||
"xo": "0.16.0" | ||
}, | ||
"xo": { | ||
"rules": { | ||
"guard-for-in": 0, | ||
"no-loop-func": 0 | ||
} | ||
} | ||
} |
@@ -1,2 +0,2 @@ | ||
# ansi-regex [![Build Status](https://travis-ci.org/sindresorhus/ansi-regex.svg?branch=master)](https://travis-ci.org/sindresorhus/ansi-regex) | ||
# ansi-regex [![Build Status](https://travis-ci.org/chalk/ansi-regex.svg?branch=master)](https://travis-ci.org/chalk/ansi-regex) | ||
@@ -16,3 +16,3 @@ > Regular expression for matching [ANSI escape codes](http://en.wikipedia.org/wiki/ANSI_escape_code) | ||
```js | ||
var ansiRegex = require('ansi-regex'); | ||
const ansiRegex = require('ansi-regex'); | ||
@@ -29,5 +29,13 @@ ansiRegex().test('\u001b[4mcake\u001b[0m'); | ||
## FAQ | ||
### Why do you test for codes not in the ECMA 48 standard? | ||
Some of the codes we run as a test are codes that we acquired finding various lists of non-standard or manufacturer specific codes. If I recall correctly, we test for both standard and non-standard codes, as most of them follow the same or similar format and can be safely matched in strings without the risk of removing actual string content. There are a few non-standard control codes that do not follow the traditional format (i.e. they end in numbers) thus forcing us to exclude them from the test because we cannot reliably match them. | ||
On the historical side, those ECMA standards were established in the early 90's whereas the VT100, for example, was designed in the mid/late 70's. At that point in time, control codes were still pretty ungoverned and engineers used them for a multitude of things, namely to activate hardware ports that may have been proprietary. Somewhere else you see a similar 'anarchy' of codes is in the x86 architecture for processors; there are a ton of "interrupts" that can mean different things on certain brands of processors, most of which have been phased out. | ||
## License | ||
MIT © [Sindre Sorhus](http://sindresorhus.com) |
New author
Supply chain riskA new npm collaborator published a version of the package for the first time. New collaborators are usually benign additions to a project, but do indicate a change to the security surface area of a package.
Found 1 instance in 1 package
4192
40
2
2