False positive validation of LWC

[dankleinsingletrack]

Summary

When attempting a push an invalid LWC, sfdx shows a success message with a list of files changed although deployment has failed and files have changed in the org.

Steps To Reproduce:

1. create an LWC component with invalid markup:
   <template>
<p<>1234567</p>
</template>

2. push using the command:
   sfdx force:source:push --json

Expected result

Error message

Actual result

The outcome - success with list of changed files, although nothing changed:
{
"status": 0,
"result": {
"pushedSource": [
{
"state": "Changed",
"fullName": "betaComponent1",
"type": "LightningComponentBundle",
"filePath": "/Users/danklein/workspace/Singletrack-Core/SingletrackDev/singletrack/main/default/lwc/betaComponent1/betaComponent1.css"
},
{
"state": "Changed",
"fullName": "betaComponent1",
"type": "LightningComponentBundle",
"filePath": "/Users/danklein/workspace/Singletrack-Core/SingletrackDev/singletrack/main/default/lwc/betaComponent1/betaComponent1.html"
},
{
"state": "Changed",
"fullName": "betaComponent1",
"type": "LightningComponentBundle",
"filePath": "/Users/danklein/workspace/Singletrack-Core/SingletrackDev/singletrack/main/default/lwc/betaComponent1/betaComponent1.js"
},
{
"state": "Changed",
"fullName": "betaComponent1",
"type": "LightningComponentBundle",
"filePath": "/Users/danklein/workspace/Singletrack-Core/SingletrackDev/singletrack/main/default/lwc/betaComponent1/betaComponent1.js-meta.xml"
}
]
}
}

System Information

bash

• If you are using sfdx
  • Run sfdx version --verbose --json
• If you are using sf
  • Run sf version AND sf plugins --core
• Paste the output here
  -{
  "cliVersion": "sfdx-cli/7.155.1",
  "architecture": "darwin-x64",
  "nodeVersion": "node-v16.15.1",
  "pluginVersions": [
  "@oclif/plugin-autocomplete 0.3.0 (core)",
  "@oclif/plugin-commands 1.3.0 (core)",
  "@oclif/plugin-help 3.3.1 (core)",
  "@oclif/plugin-not-found 1.2.6 (core)",
  "@oclif/plugin-plugins 1.10.11 (core)",
  "@oclif/plugin-update 1.5.0 (core)",
  "@oclif/plugin-warn-if-update-available 1.7.3 (core)",
  "@oclif/plugin-which 1.0.4 (core)",
  "@salesforce/sfdx-plugin-lwc-test 0.1.7 (core)",
  "alias 2.0.1 (core)",
  "apex 0.13.0 (core)",
  "auth 2.1.0 (core)",
  "community 2.0.0 (core)",
  "config 1.4.12 (core)",
  "custom-metadata 2.0.0 (core)",
  "data 2.0.3 (core)",
  "generator 2.0.1 (core)",
  "info 2.0.1 (core)",
  "limits 2.0.1 (core)",
  "org 1.13.2 (core)",
  "salesforce-alm 54.5.1 (core)",
  "schema 2.1.1 (core)",
  "sfdx-cli 7.155.1 (core)",
  "signups 1.1.2 (core)",
  "source 1.10.2 (core)",
  "telemetry 2.0.0 (core)",
  "templates 54.8.0 (core)",
  "trust 2.0.0 (core)",
  "user 2.0.2 (core)"
  ],
  "osVersion": "Darwin 21.5.0"
  }

Additional information

important to note:

1. if pushing without --json flag, (sfdx force:source:push), error message appears as expected
2. the issue happens in scratch orgs created with namespace

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[maggiben]

Hello, was this working on a previous version of the CLI ? if so which one ?

[dankleinsingletrack]

@maggiben it is, v 7.132.0 has no issue

[maggiben]

I've introduced an HTML error in our demo dreamhouse-lwc and I got these results:

and with --json

Maybe you can provide us with an org to reproduce this error, thanks !

[SCWells72]

@maggiben did you try the exact example that was provided in the description, i.e., a brand new LWC component with the following HTML body:

<template>
<p<>1234567</p>
</template>

I'm able to reproduce it with that against pretty much any org.

PS: I'm lurking on this issue because this was originally asked in the context of IC2 but since it was reproducible by both of us using only the CLI, I asked that an issue be opened here.

[maggiben]

I created a new component and try pushing, Im still getting an error:

[maggiben]

I noticed that In the example above I was nesting caseTest inside force-app/main/default/lwc/caseTest like so: force-app/main/default/lwc/caseTest/caseTest and It did not found the error.
However when I moved it back one folder up: force-app/main/default/lwc/caseTest deploy went by without noticing the error as you described.
I'll report it as a bug.

[git2gus]

This issue has been linked to a new work item: W-11385290

[mshanemc]

@SCWells72 @dankleinsingletrack I'm following your steps exactly and am on sfdx-cli/7.158.1 darwin-x64 node-v16.15.1 but can't reproduce the error

<template>
  <p<>1234567</p>
</template>

[mshanemc]

I've also tried pushing a valid version up and then changing it to be bad, and still get the same (good) error.

Can you update the CLI (plugin source is 2.0.x these days) and see if the problem has already been fixed?

[dankleinsingletrack]

@mshanemc updated sfdx and managed to reproduce

[mshanemc]

@SCWells72 @dankleinsingletrack I've made no progress with reproducing this. I made a repro-repo
https://github.com/mshanemc/gh1602-bad-lwc-validation

1. does it fail for you?
2. if not, is there anything obviously different between my repo and your setup?

[dankleinsingletrack]

@mshanemc I've cloned and attempted to repro using your repo.
It didn't fail. I noticed that you don't have namespace specified in sfdx-project.json
Added namespace, created a new scratch org and managed to repro

[mshanemc]

OK, so the namespace is the key. I wasn't using it based on what @SCWells72 said

I'm able to reproduce it with that against pretty much any org.

Thanks for checking!

[SCWells72]

@mshanemc For what it's worth, I can (or at least could; I haven't tried since the last time I responded here) reproduce this against a non-namespace org. However, if you find that you can reproduce this against a namespace org, hopefully that will lead you to the more general issue and solution.

[mshanemc]

I found the bug and we're gonna get this out today in RC

[mshanemc]

But the bug I found around this is only gonna affect non-c: namespace and so if you've got something else reproducible, then there's a 2nd, separate problem

[SCWells72]

Interesting. I just brought up the same project that reproduced this on June 30 against the latest-and-greatest CLI at that point and it no longer reproduces for me. Oh well...