Replies: 1 comment
-
Related issue: #131 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I start this discussion following this issue: #27
I clearly got tricked by
yarn.lock
, assuming the versions of the dependencies of log4brains will be the same for every users in the future.It turns out the app was not working anymore after just 3 minor version releases of Next.js, which is understandable because we heavily use "hacks" of Next.js based on its internal architecture.
So I decided to pin Next.js version to a fixed one.
But I am sure the same issue can happen again in the future with other dependencies, and I would love to hear what are the best practices on how to manage the dependencies of a global NPM package like Log4brains?
To mitigate the risks for now, I simply scheduled some end-to-end tests every week that install the app from NPM on a fresh container, and test it very roughly. But it does not feel very bulletproof.
Here are the options I have in mind so far:
npm-shrinkwrap.json
(but what about Yarn?)package.json
and use a tool like Renovate to bump them automatically on a regular basisAny other solution?
I would love to hear your opinions on this!
Beta Was this translation helpful? Give feedback.
All reactions