[sitecore-jss-react] Handle BYOC Component error

[addy-pathania]

The BYOC component should parse the passed props when fetchedDatais not present.

• This PR follows the Contribution Guide
• Changelog updated

Description / Motivation

Testing Details

• Unit Test Added
• Manual Test/Other (Please elaborate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

[art-alexeyenko]

👍

[art-alexeyenko]

One question though- do we need to modify yarn.lock each time with our PRs now?
Should we be fixing yarn.lock outside of a pull request to make it more cherry-pickable? @sc-addypathania

[addy-pathania]

One question though- do we need to modify yarn.lock each time with our PRs now? Should we be fixing yarn.lock outside of a pull request to make it more cherry-pickable? @sc-addypathania

@art-alexeyenko How would you fix the yarn.lock outside of PR?
The issue is whenever we switch branches or pull changes from the remote branch if there were any change in the dependencies then the node_modules gets corrupted. Therefore the only solution i see is to reset yarn.lock before pushing the PR.

[art-alexeyenko]

The issue is whenever we switch branches or pull changes from the remote branch if there were any change in the dependencies then the node_modules gets corrupted.

I think the issue was caused by that yarn.lock commit launched from azure pipeline automation? Now that this commit is not triggered for the previous PR merge, there's a conflict in the current one.

How would you fix the yarn.lock outside of PR?

We should only need to update yarn lock when dependencies change. So we need to ensure that unneccesary yarn.lock updates don't trigger. Until then we can try restoring a "broken" yarn.lock via a direct [skip-ci] commit perhaps.
@sc-addypathania

[addy-pathania]

I think the issue was caused by that yarn.lock commit launched from azure pipeline automation? Now that this commit is not triggered for the previous PR merge, there's a conflict in the current one.

Hmm probably but looks like this change has been there in the azure pipeline file since a very long time.

We should only need to update yarn lock when dependencies change. So we need to ensure that unneccesary yarn.lock updates don't trigger. Until then we can try restoring a "broken" yarn.lock via a direct [skip-ci] commit perhaps.

Yeah we should add something to investigate this.
Sounds good. 👍🏼