chore: ignore yarn.lock file and update example #6588
Conversation
bjohansebas
left a comment
bjohansebas
left a comment
There was a problem hiding this comment.
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. |
|
This PR will not break anything, it will break when we were rely on lockfiles and we know |
IamLizu
left a comment
IamLizu
left a comment
There was a problem hiding this comment.
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.
Yes, this will restrict the idea |
|
@UlisesGascon WDYT? |
shivarm
force-pushed
the
allow-to-use-multiple-pkg-manager
branch
from
fe26fd0 to
4c072b4
Compare
shivarm
force-pushed
the
allow-to-use-multiple-pkg-manager
branch
from
4c072b4 to
5ef70dc
Compare
|
I will merge this PR next week 👍 |
4 participants
When I used yarn then
yarn.lockgenerated, our existing.npmrcworking fornpm and pnpmbut for yarn we have to delete it after install.This will allow us to use above package manager without conflict of lock files