check `node.raw` before checking because it's not standard and may break custom parser

What rule do you want to change?

https://github.com/eslint/eslint/search?q=node.raw&type=

Does this change cause the rule to produce more or fewer warnings?

Fewer error for custom parser, raw of Literal is not standard, see https://github.com/estree/estree/issues/14

How will the change be implemented? (New option, new default behavior, etc.)?

check node.raw, return if not presented

Please provide some example code that this change will affect:

Context: https://github.com/mdx-js/eslint-mdx/pull/284#issuecomment-800399534

What does the rule currently do for this code?

break if the custom parser does not have node.raw

What will the rule do after it’s changed?

no error

Are you willing to submit a pull request to implement this change?

Yes

[wooorm]

Fewer error for custom parser, raw of Literal is not standard, see estree/estree#14

Specifically, fewer crashes.

---

My use case for this is that certain languages can compile to JavaScript. Such as markdown/MDX, and others. But those language have different and noncompatible representations of literals.

For example, in markdown, an alt attribute can be represented with ![the alt attribute](). A custom parser could represent that attribute as a JSX attribute in estree. But in those cases, setting a raw field on the literal is nonsensical: there are no quotes, escapes don‘t work, character references (&) could exist, etc.

A different solution for custom parsers would be to try and create a sensical .raw attribute. The problem with this approach though is that it now needs to know what the preferred quote style is.

So, I think a better solution would be for rules that can only work on .raw to exit gracefully if that field does not exist.

[mdjermanovic]

If the rules would use another way to get the source code, they’ll still assume that if node.type === “Literal” && typeof node.value === “string” then node is a JavaScript string literal.

Tokens? What other ways are there?

Tokens, or slicing text from the source code by node’s .range.

.raw should represent the source code as-is.

I agree, but in my use case this conflicts with the other requirement of .raw, namely that it must exist. There are languages that can be represented as an estree, but setting .raw fields would trip ESLint rules up.

Rules that need .raw are mostly rules with a purpose to check how the code was exactly written in JS and enforce some style or best practices about it. Those rules are thus not applicable to languages with a different syntax for literals.

If we treat an absence of .raw as a way to tell that it isn’t really a JS literal, that would add maintenance to rules that were designed for JS. It could also hide bugs in rules and other parsers.

ESLint can lint the JS parts fine. .raw is set there. Turning ESLint rules off means that it doesn’t lint anything.

You’ll produce a single AST with JS and non-JS parts, where some Literal nodes have .raw but some don’t?