Unofficial files in component bundles can't be viewed

Issue #1103 resolved
Daniel Morton created an issue

Since the introduction of the component sub-tab feature (which is great) we are no longer able to open other files that are in the component bundle directory.

We are keeping some jest testing files for the component in the test directory eg;-

aura/component/component.cmp aura/component/componentController.js aura/component/test/someTest.js

Since the introduction of the sub-tabs we are no longer able to open the test files. If we try to do so the component opens with the sub-tabs and we can't view or edit the test file.

Comments (7)

  1. Scott Wells repo owner

    Thanks for filing, Daniel, and sorry for the inconvenience. I actually have some local changes in another branch that will resolve this issue. I'll try to get them integrated into the build after the very next one (which will be released tomorrow morning).

  2. Scott Wells repo owner

    Daniel, I've incorporated the fix for this into what will be the next build, but I have a question about how this has been working for you previously. When I save any changes to the test JS file, IC raises an error about not being able to determine the content type for the file. This is due to both deploy-on-save and Tooling API-based Lightning deployment being enabled. I would expect that you've likely seen this error as you've been developing your Jest tests, no? If not, have you disabled deploy-on-save and/or Tooling API-based Lightning deployment? I just want to make sure that I'm not fixing one thing just to leave you with another problem right behind it.

  3. Daniel Morton reporter

    Hi Scott,

    Thanks for the fix. I've not come across the error before, we are using DX connections with Deploy on Save and the Tooling API enabled, I haven't tried with a non-scratch org. The file save does trigger a deployment but we've added the fixes to the .forceignore and we end up with an empty deployment (which is fine).

    I can't actually test at the moment as i can't save the file !

    daniel

  4. Scott Wells repo owner

    Thanks, Daniel. That certainly explains it. The SFDX CLI must be ignoring those files already. Today's build will have a partial fix for this. It will address the issue you're having with opening these test source files but not the layer below that which causes them to be reported as errors when you try to deploy against a non-DX org. I have that change as well but am holding it back for more testing before releasing it. The short version, though, is that today's build should resolve this for you.

  5. Scott Wells repo owner

    Delivered in 2.0.3.6. I'll provide a more complete solution in a subsequent build pending more testing, but the issue you've encountered should be addressed in this build. Feel free to reopen if not.

  6. Log in to comment