babel-sublime: Toggle comments broken on v10.0.0-beta2

Version: v10.0.0-beta2

Consider this little snippet:

export default function Foo(props) {
  return (
    <div>
      <Foo>
      </Foo>
    </div>
  );
}

And now try to comment/uncomment an inner block of code, ie:

showcase

You can see 2 examples of comment/uncomment not working:

If i select a block of code and comment/uncomment without selecting anything else will fail
If i select a block of code, comment and then I reselect the entire commented block it will also fail

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 1
Comments: 17 (10 by maintainers)

Most upvoted comments

The v11 beta is out, which should slightly improve JSX commenting.

Thom1729 on May 4, 2021

I typed out the example from your image and ran some tests. The behavior varies between the new and old versions of Babel, but also depending on whether you have the ST4 JavaScript package, the ST3 JavaScript package, or whether the JavaScript package is disabled. The only case in which it works correctly is with the old babel-sublime and the ST3 JavaScript package enabled.

The root cause of the issue is https://github.com/sublimehq/sublime_text/issues/2152. When Sublime tests the scope source.js meta.jsx source.js.embedded, the selector meta.jsx will outscore source.js, which is arguably wrong. This is inevitably going to cause problems with alternating nested scopes like the one in your example. (I tested with simpler code that did not include alternating nesting, and v10.0.4 should improve behavior in similar cases.)

It may be possible to hack the comment rules to produce better results in your example. But I’m thinking that the best solution might be to write an alternate commenting command that handles these cases in a more robust manner. (See, for example, the jsx_close_tag command from JS Custom.) Unfortunately, that’s probably not a quick fix. I’ll play around with this today and see how it looks.

Thom1729 on Apr 16, 2021

@skizzo I’ve released version 10.0.2 with a fix for that specific case. It’s monkeypatched onto the compiled syntax definition, which is not great, but when v11 comes around everything should be in accord.

The fix does not address the issue @brupelo reports; that part of the upstream fix can’t easily be backported for ST3.

Thom1729 on Apr 13, 2021

Yeah, this is definitely a bug. This case was also broken on the old version, so it’s not a regression, but it still deserves a fix.

I’ve already submitted a fix for the ST4 JSX package. That particular fix will end up in babel-sublime when:

The PR is merged (and I’ve rebased JS Custom).
I release a ST4 build for babel-sublime.

Depending on how things look over the next few days, it may make sense to backport something to v10.

Thom1729 on Apr 13, 2021

I have the exact same problem, and am looking for a solution. On my other development environment, Sublime Text 3 still uses v8.6.3 of this package, and it’s working there.

So my question is: Does anybody know how to force Sublime Text to use a specific version of a package?

skizzo on Apr 13, 2021