Consider stripping a leading and trailing slash from configuration property keys

[remcohaszing]

🚀 Feature Proposal

Consider stripping a leading and trailing slash (/) from configuration property keys if the key represents a regular expression.

Motivation

This would allow to use an actual regular expression in several configuration locations. This adds syntax highlighting and linting capabilities to regular expressions used in Jest configuration, and removes the need to use double backslashes.

Example

From the moduleNameMapper example configuration

{
  "moduleNameMapper": {
    "^image![a-zA-Z0-9$_-]+$": "GlobalImageStub",
    "^[./a-zA-Z0-9$_-]+\\.png$": "<rootDir>/RelativeImageStub.js",
    "module_name_(.*)": "<rootDir>/substituted_module_$1.js"
  }
}

In JavaScript, this could be written as

module.exports = {
  moduleNameMapper: {
    [/image![a-zA-Z0-9$_-]+$/.source]: 'GlobalImageStub',
    [/^[./a-zA-Z0-9$_-]+\.png$/.source]: '<rootDir>/RelativeImageStub.js',
    [/module_name_(.*)/.source]: '<rootDir>/substituted_module_$1.js'
  }
}

It would be great if the .source could simply be removed

module.exports = {
  moduleNameMapper: {
    [/image![a-zA-Z0-9$_-]+$/]: 'GlobalImageStub',
    [/^[./a-zA-Z0-9$_-]+\.png$/]: '<rootDir>/RelativeImageStub.js',
    [/module_name_(.*)/]: '<rootDir>/substituted_module_$1.js'
  }
}

However, the last example won’t work currently, because RegExp.prototype.toString() adds a preceding and a trailing slash.

Pitch

This implements a feature regarding the parsing of jest.config.js.

[SimenB]

Definitely! Right now we have quite a bit of new RegExp spread around, would be great to consolidate it all to normalize in jest-config. Then we could do a check if the input is already a regex before calling new RegExp on it. I'm not sure how much work that would be, but just greping for new RegExp didn't show too much so it might not be too bad.

Wanna send a PR for it?

[alexanderbird]

For what it's worth: I've written a failing test for the moduleNameMapper example.

master...alexanderbird:support-regexp-configuration-keys

Not sure when I'll be able to come back to this, so if anyone else wants to run with it don't let me stop you :)

---

Incidentally, that unit test I added to is looking pretty long, is there any reason I shouldn't split it up into separate tests for each expectation?

[SimenB]

Incidentally, that unit test I added to is looking pretty long, is there any reason I shouldn't split it up into separate tests for each expectation?

Feel free to split it up into logical parts!

[alexanderbird]

@SimenB it looks like RegExp literals get toString()ed when the object is initialized, so when we normalize it it's already a string -- so there's no way to tell between a RegExp literal and a string surrounded by slashes.

I can update the documentation to warn about this, but before I continue I want to confirm that's an ok solution.

I've written a minimal solution to normalize the strings:
master...alexanderbird:support-regexp-configuration-keys

[SimenB]

it looks like RegExp literals get toString()ed when the object is initialized

Can we change that?

[remcohaszing]

No,sorry, I thought this was clear.

Object keys are always strings. The string representation of a RegExp contains a leading and a trailing slash. So my idea was to strip the leading and trailing space if the object key looks like a string representation of a RegExp object.

So this:

module.exports = {
  moduleNameMapper: {
    [/foo/]: 'bar',
  }
}

Equivalent to:

module.exports = {
  moduleNameMapper: {
    '/foo/': 'bar',
  }
}

Would be interpreted as this:

module.exports = {
  moduleNameMapper: {
    'foo': 'bar',
  }
}

[github-actions]

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity. Please open a new issue if the issue is still relevant, linking to this one.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.