Thank you for your great tutorial, It was very enlightening to me, But I have a little of different view, I think deleting package-lock.json will cause the package version to get out of control, It is a bad practice, Perhaps we can use npm i PAKEAGE_NAME@x.x.xto solve the release problem
That's definitely a great option if it works. Deleting package-lock.json in a mature application absolutely creates a risk of introducing bugs with package interactions, even between minor and patch versions.
That said, although removing the file may be bad practice, I would be interested to see if your solution works for initializing Storybook in an existing project and creating a stable alignment between all the peerDependencies. That's the issue that gets fixed with a fresh npm install and I'm not sure if harcoding the versions of each package fixes that issue (I'd be happy to be wrong though).
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thank you for your great tutorial, It was very enlightening to me, But I have a little of different view, I think deleting
package-lock.json
will cause the package version to get out of control, It is a bad practice, Perhaps we can usenpm i PAKEAGE_NAME@x.x.x
to solve the release problemThat's definitely a great option if it works. Deleting
package-lock.json
in a mature application absolutely creates a risk of introducing bugs with package interactions, even between minor and patch versions.That said, although removing the file may be bad practice, I would be interested to see if your solution works for initializing Storybook in an existing project and creating a stable alignment between all the
peerDependencies
. That's the issue that gets fixed with a freshnpm install
and I'm not sure if harcoding the versions of each package fixes that issue (I'd be happy to be wrong though).