Reference for stage 3 regex-escaping

[Josh-Cena]

Part of #36915

[github-actions]

Preview URLs

• /en-US/docs/Web/JavaScript/Guide/Regular_expressions
• /en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp/escape
• /en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp
• /en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replaceAll
• /en-US/docs/Web/JavaScript/Reference/Regular_expressions

Flaws (1)

Note! 4 documents with no flaws that don't need to be listed. 🎉

URL: /en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp/escape
Title: RegExp.escape()
Flaw count: 1

• bad_bcd_queries:
  • No BCD data for query: javascript.builtins.RegExp.escape

External URLs (1)

URL: /en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp/escape
Title: RegExp.escape()

• https://github.com/zloirock/core-js (1 time) (Note! This may be a new URL 👀)

(comment last updated: 2024-11-29 02:59:28)

[hamishwillee]

@Josh-Cena Looks great. I don't fully understand this gist linked from the proposal. But I take it to mean there might be risky places to insert the literal, even escaped. I assume this is to an issue because you would have mentioned it.

As an aside, you link to the escape sequence https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions#escape_sequences
The proposal escapes space in its example - I don't see space mentioned in the list. Might not be important - just noting in case it is an omission.

[Josh-Cena]

Oh I forgot to ask but @ljharb @bakkot your reviews will be appreciated too. Thanks!

[ljharb]

are you still only linking to core-js polyfills? if not, it'd be great to include https://www.npmjs.com/package/regexp.escape

[Josh-Cena]

I personally would not object, but I would need to see what others say. In the meantime let's hold the same policy that other maintainers have found acceptable, which is to only consistently include core-js polyfills. Hope you would understand.

[ljharb]

Sure. Where can I go to revisit this discussion? Last time I tried it never went anywhere, and another polyfill maintainer tried recently and it seemed to get overly heated.

[Josh-Cena]

I'll discuss it internally.

[Josh-Cena]

It looks we still hold https://github.com/orgs/mdn/discussions/475 as our conclusion; i.e. as long as someone steps out to endorse es-shims we are happy to add it, and we should formally document a list of trusted polyfill sources and reject everything not in this list (with another process to endorse more). I'm happy to add es-shims, but I'm too busy to initiate the process in the next few months.

[ljharb]

Who would need to endorse it? Who endorsed core-js originally? Does it require an MDN team member to initiate the process, or can I?

[Josh-Cena]

Who endorsed core-js originally?

I think that endorsement was implicitly given due to its wide usage via Babel. Happy to formalize the decision in the meta docs.

Who would need to endorse it? Does it require an MDN team member to initiate the process, or can I?

Just someone who raised a PR and got it merged without any objections. We don't know exactly yet as it's entirely new to us. I bet you can, too, as long as you get multiple feedback on your PR. I imagine it would be put under either https://developer.mozilla.org/en-US/docs/MDN/Writing_guidelines/What_we_write/Criteria_for_inclusion or https://developer.mozilla.org/en-US/docs/MDN/Writing_guidelines/Writing_style_guide#external_links, as a new section called "Inclusion of polyfills" that basically restates the conclusion in https://github.com/orgs/mdn/discussions/475 and say "we only allow polyfills from trusted sources, which are the following:"

[hamishwillee]

This is good to go from my perspective. I'll approve this when you let me know the discussions with the technical experts have wound down.

[Josh-Cena]

I believe I've addressed all reviews.

[hamishwillee]

Thanks very much for this @Josh-Cena - also @bakkot @ljharb