Inside a Node.js project, it's not clear to me what the correct workflow would be to upgrade a package to a major release.
Let's suppose I'm installing stylelint:
npm install --save stylelint
By default that installation puts the string "stylelint": "^8.4.1" inside my package.json file, which means that if I want to update it with npm update, I will get only minor and patch releases (8.4.2 is ok, 8.5.0 is ok, 9.0.0 is not).
If I check with npm outdated and it comes out that I could update to 9.0.0, npm update won't get me to that state because of the restriction depicted above.
So, if I want to upgrade, what am I supposed to do?
Must I manually modify my package.json to stylelint version ^9.0.0, delete the node_modules directory, and re-run npm install?
Or should I remove the ^ character to let npm update do its job?
What is the common/best practice to adopt?
Or maybe I have just to remove the ^ character to let npm update do its job?
What is the common/best practice to adopt?
The most common/best practice is to never allow automatic updates to versions that have potentially breaking changes. Workflows are all over the map, from; manual test and then update packages.json, to fully automated detect, test, update and submission of packages.json.
Many Java/JavaScript environments are particularly sensitive to transitive dependency changes due to the lack of side by side versioning support. If your package brings in a breaking change of one of its own dependencies, then your package has introduced a breaking change to the system. If your 1.y.z causes an update of one of its dependencies from X.Y.Z to X+1.Y.Z it introduces a breaking change and is therefore not a stable version 1.y.z. Other packages that depend on the same package name as yours could potentially be broken whenever the developers of that package released a breaking change. Never let the world get into that state!
I recommend you study the Diamond Dependency Problem and take to heart. You should always carefully test breaking changes and never try to force them on your customers.
As pointed out by @ShaharShokrani, this answer gives a good workflow for manually updating your package. And to remain in compliance with SemVer 2.0.0 #8, don't forget to bump your own major version number.