Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add @babel/plugin-transform-named-capturing-groups-regex #7105

Merged
merged 4 commits into from Jan 15, 2019

Conversation

nicolo-ribaudo
Copy link
Member

@nicolo-ribaudo nicolo-ribaudo commented Dec 25, 2017

Q                       A
Fixed Issues? babel/proposals#35
Patch: Bug Fix?
Major: Breaking Change?
Minor: New Feature? yes
Tests Added + Pass? Yes
Documentation PR
Any Dependency Changes? regexp-tree
License MIT

When the runtime flag is on, this plugin adds a new helper which wraps the native RegExp class to provide groups support. People nees to use a polyfill (I implemented it in core-js) for browsers that don't support overwriting regexp methods.

@@ -0,0 +1 @@
/(?<\u{41}>)\k<\u{41}>/;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DmitrySoshnikov I think that regexp-tree should throw on this regex, since unicode escapes are only alloed when there is the u flag?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, @Golmote added generic support for Unicode to parser (DmitrySoshnikov/regexp-tree#114); we should also check the group names, if they are allowed only with u flag (since by itself \u{41} can normally be used without u flag -- "u repeated 41 times").

If you're positive from spec, that it should throw, we should open an issue. Thanks for catching it!

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure identity escapes don't throw without the u flag.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Golmote, right, however this one is specifically for a capturing group name, like in (?<\u{41}>). I'll need to double-check the spec, but seems, yes, it should throw, and be an invalid name for a group if no u flag is passed.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I read too fast 😳

@babel-bot
Copy link
Collaborator

babel-bot commented Dec 25, 2017

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/9800/

@existentialism existentialism added the PR: New Feature 🚀 A type of pull request used for our changelog categories label Dec 26, 2017
"regexp",
"regular expressions"
],
"repository": "https://github.com/babel/babel/tree/master/packages/babel-plugin-transform-named-capturing-groups-regex.git",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please remove the .git as the end here?

@nicolo-ribaudo
Copy link
Member Author

The tests are failing because regexp-tree only works on node >= 6.
@mathiasbynens I will work on implementing named groups in regexpu-core (I already opened the parser PR some days ago: jviereck/regjsparser#83)

@DmitrySoshnikov
Copy link
Contributor

The tests are failing because regexp-tree only works on node >= 6.

Thanks for the notice! Just an FYI, I removed node >= 6 restriction in 0.0.78, and now support older Node versions.

@nicolo-ribaudo
Copy link
Member Author

Proposal merged - tc39/ecma262#1027 (comment)

}, Object.create(null));
}

wrap(RegExp.prototype, "exec", function(f, str) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is effectful, I understand that it's hard (impossible?) to implement this feature without actually messing with built in prototypes - but when that is the case I feel like it should not be a part of babel-helpers, but rather babel-polyfill

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zloirock Does corejs polyfill support for [String.replace] and overwritten exec? If it does, we can remove thi "compat" helper from Babel.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nicolo-ribaudo core-js supports @@replace, but does not overwrite exec.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I didn't explain myself correctly. Every RegExp method (or string method which uses regexs) should use exec internally. e.g.

class MyRegExp extends RegExp {
  exec() {
    return ["foo", "bar"];
  }
}

"abc".match(new MyRegExp("b")); // ["foo", "bar"]

If it doesn't work in core-js, I could open a PR

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

core-js provides a naive realisation of support RegExp-related well-known symbols and use original methods like String.prototype.match or String.prototype.replace. It's done for reducing slowdown in wrappers. However, now it should not cause too many problems, so feel free to add a PR with adding this logic.

helpers.wrapRegExp = defineHelper(`
var kGroups = Symbol("@@babel/groups");

function BabelRegExp(re, groups) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could this be wrapped in an iife? all those assignments at the moment will prevent tree-shaking if BabelRegExp class stays unused. Im not sure if we can annotate helper as #__PURE__ at the moment though (I think comments in the helpers are ignored)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could probably also use a redefining helper technique here to contain this whole declaration within a single top level node

it seems though that it would actually be cleaner if we could transpile helpers with user settings - this could be written as an actual class

@DmitrySoshnikov
Copy link
Contributor

Is this PR ready to me merged?

@damianobarbati
Copy link

Can this be merged @nicolo-ribaudo ?

@DmitrySoshnikov
Copy link
Contributor

Is this ready for merge?

if (result) result.groups = buildGroups(result, this);
return result;
};
BabelRegExp.prototype[Symbol.replace] = function(str, substitution) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that I will move this whole method to core-js (I already moved the first part)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably it is better to leave it there, otherwise even es6+ browsers require core-js

@iheanyi
Copy link

iheanyi commented Nov 7, 2018

Any updates on this PR y'all?

export default function({ types: t }, options) {
const { runtime = true } = options;
if (typeof runtime !== "boolean") {
throw new Error(".runtime must be boolean");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Is the period necessary?

"repository": "https://github.com/babel/babel/tree/master/packages/babel-plugin-transform-named-capturing-groups-regex",
"bugs": "https://github.com/babel/babel/issues",
"dependencies": {
"regexp-tree": "^0.0.78"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we bump to latest (85)?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, let's use the latest version.

@existentialism
Copy link
Member

This still needs zloirock/core-js#435 to be published, yea?

/cc: @zloirock

@nicolo-ribaudo
Copy link
Member Author

Yeah, It hasn't been released yet.

@zloirock
Copy link
Member

@existentialism we need a backport of zloirock/core-js#453 to v2 branch. I'll try to test it with v3 branch and publish a new beta release at this weak.

@nicolo-ribaudo
Copy link
Member Author

Oh right, I will backport it.

@nicolo-ribaudo
Copy link
Member Author

core-js was just updated, I'll update this PR soon.

Copy link
Member

@existentialism existentialism left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍, I'll follow this up with preset-env support!

Thanks @zloirock for the support as well!

@DmitrySoshnikov
Copy link
Contributor

@nicolo-ribaudo, what's the status on this? You can also update to the latest v. 0.1.0.

@billyjanitsch
Copy link

Wanted to cross-reference DmitrySoshnikov/regexp-tree#170. regexp-tree brings in a bunch of large CLI dependencies including an old version of yargs, which significantly increases the install size of @babel/preset-env (due to #9345). It would be great to have these moved to a separate CLI package, if possible.

cc @DmitrySoshnikov @existentialism

@DmitrySoshnikov
Copy link
Contributor

@billyjanitsch, yes, we'll be separating the CLI (and potentially other modules) into its own npm package.

@DmitrySoshnikov
Copy link
Contributor

DmitrySoshnikov commented Feb 18, 2019

Note: as of v1.1.5 the CLI is split into its own module, so the size of the regexp-tree is reduced significantly.

@lock lock bot added the outdated A closed issue/PR that is archived due to age. Recommended to make a new issue label Oct 4, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
outdated A closed issue/PR that is archived due to age. Recommended to make a new issue PR: New Feature 🚀 A type of pull request used for our changelog categories
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet