gkz/levn

Light ECMAScript (JavaScript) Value Notation - human written, concise, typed, flexible

levn's Issues

Escape sequences in quoted string literals are handled unintuitively

It makes sense for non-quoted strings to be treated as literally as possible. However, quoted string literals (which have their quotes stripped) should probably be treated as close to normal JavaScript strings as possible, so that data read by levn could also be compatible with JSON or other interchange formats.

const assert = require("assert");
const levn = require("levn");

const result1 = levn.parse("String", `\r\n`);
assert.equal(result1, "\\r\\n");  // Passes

const result2 = levn.parse("String", `"\r\n"`);
assert.equal(result2, "\r\n");  // Fails

Put another way, it seems to be impossible to parse a string in levn so that the resulting string has escape sequence characters such as \n.

---

This is causing some weird behavior in ESLint when parsing inline configuration comments. This example is kind of involved, so please bear with me.

1. A user can specify a regular expression (as a string) for the ESLint rule to use to ignore certain lines of code:

   /* eslint max-len: ["error", 80, { ignorePattern: "require\\(" }] */

2. If ESLint parses this file, it's supposed to activate the max-len rule and use the string as a regex pattern.

3. When this pattern is used in an ESLint configuration file, it works as expected and looks for lines with "require(" in them.

4. When we use levn to handle the inline configuration comment, the backslashes are doubled, so as to be treated literally. This results in a regex /require\\(/, which results in a SyntaxError because of the unmatched capturing parentheses.

So what I'm proposing is, if a string literal is quoted, it should only escape the backslashes if they don't make a sensible escape (i.e., the same way JavaScript handles string literals). I think unquoted string literals could still be handled with all backslashes treated literally.

Not sure if this should be considered a bug or a breaking change.

`[String]` parsing behavior

Related to gkz/optionator#34

I think there's a bug when levn parses strings with a leading slash and spaces. See the second example here - a single string is returned with the space character removed.

> levn = require("levn")
{
  VERSION: '0.4.1',
  parse: [Function: parse],
  parsedTypeParse: [Function: parsedTypeParse]
}
> levn.parse("[String]", "/Volumes/Macintosh\ HD/Users/test/foo/bar")
[ '/Volumes/MacintoshHD/Users/test/foo/bar' ]
> levn.parse("[String]", "/Volumes/Macintosh HD/Users/test/foo/bar")
[ '/Volumes/MacintoshHD/Users/test/foo/bar' ]
> levn.parse("[String]", "Volumes/Macintosh HD/Users/test/foo/bar")
[ 'Volumes/Macintosh HD/Users/test/foo/bar' ]
> levn.parse("[String]", "/Volumes/Macintosh HD/Users/test/foo/bar")
[ '/Volumes/MacintoshHD/Users/test/foo/bar' ]
> levn.parse("[String]", "'/Volumes/Macintosh HD/Users/test/foo/bar'")
[ '/Volumes/Macintosh HD/Users/test/foo/bar' ]
> levn.parse("[String]", "'/Volumes/Macintosh HD/Users/test/foo/bar'")

Possible typo in src/cast.ls?

Hi, first of all, just want to say thanks for working on a fix for #2! Really appreciate it, and this is going to help the ESLint project.

I happened to read through the diff, and I'm wondering if there is a typo that could cause problems in the latest release. There is a token "repalce", which I assume would be "replace". See below link to review in context.

levn/src/cast.ls

Line 64 in 0c5f341

type: 'Just', value: repalce that.1, "'"

If I'm totally wrong, then I apologize for wasting your time. Please feel free to close the issue if that is the case.