but what about, when you keep these overrides? you fall behind eventually and it's quite labor intensive changing these overrides over and over... What is a package stops in development? (maintainer quits, no ownership transfer.. abandoned lib in essence) If you remove it, it can lead to breakage of other things.. Yet, it's vulnerable.. using an alternative package, can also lead to breaks, since it might not support the needed elements or communicates differently (function names, class names etc, which would mean rewriting you logic code.) Also, who audits this? and on what level? (security, stability, features, etc)
We use a tool called renovate to help automatically keep npm packages upto date. If you haven't used Renovate before, it will watch for new versions of packages you are using and create a PR for them. You can even configure it on a package by package bases to automatically merge the PRs immediately or after a stabilization period. It is silver bullet as there are package incompatibilities as you have mentioned above that break tests, lint, etc that you need to fix manually but it does cut down the amount of effort overall when managing many npm packages. It also means that your always up to date so upgrading packages becomes easier since the gap between your current version and the target version will be much smaller.
Thank you, but this wasn't very helpful to me. To be able to write a simple "Hello World" application in React I need thousands of packages that occupy hundreds of MB in disk. I'm trying to learn React and most of the time when I try to install packages using npm, I get dozen (sometimes hundreds) of vulnerabilities. I spend a lot of time trying to fix those vulnerabilities and very often this number gets even bigger. Anyone who thinks this is normal is not normal. React is not for normal people.
You are a life saver, thank you bro
Happy to help.
Thank you for such short and effective solution!
Thanks You Saved My life
and earned a subscriber
but what about, when you keep these overrides? you fall behind eventually and it's quite labor intensive changing these overrides over and over...
What is a package stops in development? (maintainer quits, no ownership transfer.. abandoned lib in essence) If you remove it, it can lead to breakage of other things.. Yet, it's vulnerable.. using an alternative package, can also lead to breaks, since it might not support the needed elements or communicates differently (function names, class names etc, which would mean rewriting you logic code.)
Also, who audits this? and on what level? (security, stability, features, etc)
We use a tool called renovate to help automatically keep npm packages upto date. If you haven't used Renovate before, it will watch for new versions of packages you are using and create a PR for them. You can even configure it on a package by package bases to automatically merge the PRs immediately or after a stabilization period. It is silver bullet as there are package incompatibilities as you have mentioned above that break tests, lint, etc that you need to fix manually but it does cut down the amount of effort overall when managing many npm packages. It also means that your always up to date so upgrading packages becomes easier since the gap between your current version and the target version will be much smaller.
thank you, it worked.
Thank You Bro. God bless you.......
literally saved 5 days of work. Thank you soo much!!
Glad it helped!
Does overrides with npm packages work the same way with yarn?
I believe you would use resolutions. I’d have to look into it to see if things have changed since yarn classic versus modern.
Thanks so much
How to use overrides in monorepo?
Without npm update can we fix vulnerabilities
man, i love u
Thank you, but this wasn't very helpful to me. To be able to write a simple "Hello World" application in React I need thousands of packages that occupy hundreds of MB in disk. I'm trying to learn React and most of the time when I try to install packages using npm, I get dozen (sometimes hundreds) of vulnerabilities. I spend a lot of time trying to fix those vulnerabilities and very often this number gets even bigger. Anyone who thinks this is normal is not normal. React is not for normal people.