Multi-file editor approach for Lightning Web Components (LWCs) interferes with JS debugging / testing workflow

Issue #1344 resolved
Alan Birchenough created an issue

I could easily have missed a setting here or something, but I seem to be running into some snags as a result of the decision to show LWC files as multiple tabs in the same edit window. For most purposes this approach is great, but when debugging or trying to understand test failures, IJ navigates by default to the HTML editor tab rather than the JS one.

Here are a couple of repro scenarios:

  1. I run a Jest test. It fails, and gives me a stack trace. I click on a stack trace link, but that sends me to the HTML tab, thereby obscuring the JS I am trying to look at;
  2. I set a breakpoint during debugging, and run until the breakpoint hits. IC navigates to the HTML tab for the LWC in which the breakpoint hit occurred, rather than showing me the JS.

    1. If I then go on to step through the code, the IC editor flips back to the first tab every single step I take. This is painful. Fortunately I don’t have to step through code very often.

In both of the above cases I must click the mouse on the JS tab to regain visibility of the code I am trying to debug.

Further complications can arise because the Jest test JS often appears in the same editor as the LWC JS being tested. and then sometimes IC insists on showing me the test when I want to see the LWC JS, or vice versa. (I haven’t yet quite figured out all the antecedent conditions leading to variations on this behavior.)

I was wondering if there was, or could be, an IC or IJ setting to show me these files in separate editor windows rather than as multiple tabs in the same window? Or perhaps there is a less drastic work-around here that I am not aware of?

Overall, I have to say that so far developing LWC in IC / IJ has been a great experience, so this is a relatively minor issue.

Comments (8)

  1. Scott Wells repo owner

    No, you're exactly right, Alan. Honestly, it's because I'm somewhat abusing the tabbed editor concept in the plugin SDK right now. It's intended to present multiple views of a single file, but I'm using it to present views of multiple related files. As a result, when a file in the tabbed editor set that's already open is requested, for example as you're stepping through code in a debugger or via the global search function, I don't receive any kind of notification to bring the correct tab forward. I've been talking to JetBrains about this, and they're going to help with a few aspects, but overall I don't expect a full solution from them until a multi-file tabbed editor concept is added.

    Having said that, I have a type of workaround locally that is aware of the context in which a file is requested for being opened--specifically in a debugger--and limits the tabs shown in the tabbed editor to have the one being debugged at the "front". It mostly resolves the testing issue, though there are still corner cases that can lead to the behavior you describe.

    I'm hoping to include minimally that change in one of the upcoming builds...hopefully something even better to improve this situation. The tabbed editors are valuable enough for bundles that I don't want to lose them, but obviously there's great value in the interactive debugger for Jest tests and similar.

    I'll use this issue as a forum for tracking progress. Thanks for filing!

  2. Alan Birchenough reporter

    Well, like I said, this approach is a good fit for LWC from most points of view and only lets us down a little in a couple of use cases. Thanks for the thoughtful response. I look forward to seeing additional work-around options. Thanks for all that you do, as always.

  3. Scott Wells repo owner

    Tomorrow's build will include a partial fix for this. For the most part the correct tab should be selected for the given file now when debugging Jest tests, selecting search results, etc., in tabbed editors. Unfortunately due to limitations in the plugin SDK, what I'm including tomorrow is likely going to be about as good as it will get until there's more first-class plugin SDK support for tabbed editors that display multiple files.

  4. Scott Wells repo owner

    The aforementioned improvement was delivered with I'm going to resolve this given that it's likely as much as I can do with the current plugin SDK limitations. Of course, if it doesn't work as described please let me know so I can investigate.

  5. Scott Wells repo owner

    FYI, the next build (targeting tomorrow morning for release) will have another attempt to address this issue with proper sub-tab selection. Please let me know your experience after updating.

  6. Log in to comment