Update tooling LWC to use new deploy response #87
Conversation
| } | ||
| return successes; | ||
|
|
||
| if (deployment.diagnostics.length > 0) { |
There was a problem hiding this comment.
I don't completely understand this part, aren't diagnostics in this scenario exclusive to a failure ?
There was a problem hiding this comment.
Yeah this is a bit weird. Because of the nature of tooling api we can have some files succeed when upserting pieces of a bundle and some not. I figured if at least some succeeded we'd set the status of the component to "Changed" but there could be a diagnostic for a piece that didn't succeed. I'm not the biggest fan of this but not sure if it should be reported as Failed if some parts did work, what do you think?
There was a problem hiding this comment.
If some files fail while others don't, do the files that did succeed get reverted? Or are they still deployed? If there is a partial deployment, then I think it makes sense to keep the status as Changed so the user knows that some pieces were actually deployed.
Sidenote, if we keep the status as Changed, in the vs code side would we still display the diagnostics for the failed portion with the "Failed" progress notification?
There was a problem hiding this comment.
Because tooling is granular (one transaction per file instead of component) there won't be a revert unlike metadata api.
Sidenote, if we keep the status as Changed, in the vs code side would we still display the diagnostics for the failed portion with the "Failed" progress notification?
Yeah I think it would be something like that. Your comment just made me realize I forgot to actually include the file the diagnostic is related to in the type 🤦 , need to update that
What does this PR do?
Update tooling lwc to use new deploy response
What issues does this PR fix or reference?
@W-7853909@