chore: ignore yarn.lock file and update example

[shivarm]

When I used yarn then yarn.lock generated, our existing .npmrc working for npm and pnpm but for yarn we have to delete it after install.

This will allow us to use above package manager without conflict of lock files

[bjohansebas]

I don't have a strong opinion here, since there's also devEngines and we could probably enforce using only npm.

[shivarm]

I don't have a strong opinion here, since there's also devEngines and we could probably enforce using only npm.

I think devEngines will break the idea of using multiple packagemanager. But this will allow us to use any packagemanager since we are not pushing lockfile, so no conflicts.

[shivarm]

This PR will not break anything, it will break when we were rely on lockfiles and we know pnpm and yarn both have their lockfiles but for npm and pnpm our configuration working, means lockfile not generating while dependencies install step, but for yarn it is not working.

[IamLizu]

I don’t have a strong opinion here either – ignoring yarn.lock to avoid lockfile conflicts when using Yarn makes sense if we want true multi–package-manager support.

We could also explore enforcing a single manager via devEngines as @bjohansebas said, but that’d be a more restrictive approach.

Given that this change is harmless for npm/pnpm users and just skips committing the Yarn lockfile, I’m happy to approve.

[shivarm]

We could also explore enforcing a single manager via devEngines as @bjohansebas said, but that’d be a more restrictive approach.

Yes, this will restrict the idea

[shivarm]

@UlisesGascon WDYT?