I have the following statements in my Lightning component's Javascript controller:

console.log(/.*/.test("asd")); // prints "false"
console.log(/(.*)/.test("asd")); // prints "true"

When I run the exact same commands in the browser's console, they both print true. Of course, since they're semantically the same.

What is happening?

  • When I check your RegEx at regexr.com, it doesn't show up as being valid; (particularly the last backslash) unless JS uses a backslash instead of a forward slash as an escape; which doesn't appear to be the case based on the rest of your RegEx pattern.
    – crmprogdev
    Commented Feb 27, 2017 at 13:52
  • @crmprogdev The backslashes are indeed Javascript escape characters and used to escape the literal forward slashes, as forward slashes are regex delimiters in Javascript. The expressions work fine when I test them at regexr.com. Could you clarify? Commented Feb 27, 2017 at 16:02
  • I hadn't replaced the outer parens with square brackets, so it does indeed show as being valid. I did also see something at developer.salesforce.com/docs/atlas.en-us.lightning.meta/… which might apply. Not all JS can be used within lightning components. This may be one of those use cases. You may want to install the linter and check.
    – crmprogdev
    Commented Feb 27, 2017 at 16:07
  • See below... It even mangles it inside a string.
    – Charles T
    Commented Sep 15, 2017 at 16:01

4 Answers 4


The reason for this seems to be that the framework replaces the first line's asterisk character with the \u002A Unicode escape sequence before serving the files to the browser.

I'd report a bug if it was possible. Hopefully someone here can raise the issue!

  • I don't have any idea why the framework would escape characters in Javascript outside of strings. Or why the parentheses stop it. Seems like overzealous XSS prevention. Commented Mar 2, 2017 at 14:09
  • I've had strange outcomes too - take a look at this one which is now solved but at the time was very puzzling. salesforce.stackexchange.com/questions/127150/…
    – Charles T
    Commented Sep 15, 2017 at 15:58

Ye, as you mentioned it is framework's doing. For some reason it converts asterisk in case it is immediately followed by a slash:

new RegExp(/.*/)

would result as

new RegExp(/.\u002A/)

And the parenthesis removes the "immediately followed" situation.


Check out how it even mangles a string...


This logs correctly (because those are JS escape sequences) but the debugger call reveals it's been changed to: console.log('/.\u002A/')

I had a similar issue here which has been resolved but evidently yours hasn't: String literals with {} braces may get mangled in Lightning JS

  • 2
    That being said, if you construct it with RegExp instead, new RegExp('.*'), then the escaping Lightning does won't hurt you anymore.
    – Charles T
    Commented Sep 15, 2017 at 16:05

Has this question ever been resolved? I am having the same problem developing a component for the Lightning console.

var regex = new RegExp('.*', 'i');

gets converted to:

var regex = new RegExp('.\u002A', 'i');

It seems to however be creating the regex correctly,

> /.*/i

but while debugging the code it can really throw you off.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .