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
Uh oh!
There was an error while loading. Please reload this page.
-
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