It’s actually fairly easy, but it requires making your lexer a little smarter than usual.
The division operator must follow an expression, and a regular expression literal can’t follow an expression, so in all other cases you can safely assume you’re looking at a regular expression literal.
You already have to identify Punctuators as multiple-character strings, if you’re doing it right. So look at the previous token, and see if it’s any of these:
. ( , { } [ ; , < > <= >= == != === !== + - * % ++ --
<< >> >>> & | ^ ! ~ && || ? : = += -= *= %= <<= >>= >>>=
&= |= ^= / /=
For most of these, you now know you’re in a context where you can find a regular expression literal. Now, in the case of ++ --, you’ll need to do some extra work. If the ++ or -- is a pre-increment/decrement, then the / following it starts a regular expression literal; if it is a post-increment/decrement, then the / following it starts a DivPunctuator.
Fortunately, you can determine whether it is a “pre-” operator by checking its previous token. First, post-increment/decrement is a restricted production, so if ++ or -- is preceded by a linebreak, then you know it is “pre-“. Otherwise, if the previous token is any of the things that can precede a regular expression literal (yay recursion!), then you know it is “pre-“. In all other cases, it is “post-“.
Of course, the ) punctuator doesn’t always indicate the end of an expression – for example if (something) /regex/.exec(x). This is tricky because it does require some semantic understanding to disentangle.
Sadly, that’s not quite all. There are some operators that are not Punctuators, and other notable keywords to boot. Regular expression literals can also follow these. They are:
new delete void typeof instanceof in do return case throw else
If the IdentifierName you just consumed is one of these, then you’re looking at a regular expression literal; otherwise, it’s a DivPunctuator.
The above is based on the ECMAScript 5.1 specification (as found here) and does not include any browser-specific extensions to the language. But if you need to support those, then this should provide easy guidelines for determining which sort of context you’re in.
Of course, most of the above represent very silly cases for including a regular expression literal. For example, you can’t actually pre-increment a regular expression, even though it is syntactically allowed. So most tools can get away with simplifying the regular expression context checking for real-world applications. JSLint’s method of checking the preceding character for (,=:[!&|?{}; is probably sufficient. But if you take such a shortcut when developing what’s supposed to be a tool for lexing JS, then you should make sure to note that.