Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './v4' is not defined by "exports" package.json
CSharpDaddy opened this issue · 5 comments
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './v4' is not defined by "exports" in C:\Users\jaden\Desktop\Hye\node_modules\uuid\package.json
Does anyone know why this is happening? Im using the latest node.js version
Are you doing import ... from 'uuid/v4' anywhere in your code?
Please check the discussion in #584. Issues like this are with absolute certainty due to badly defined dependency version ranges. Please make sure that your code and all dependencies you are using make proper use of Semantic Versioning version ranges.
The whole purpose of Semantic Versioning is to provide library authors with a way for safely introducing breaking changes, and developers with a safe way of dealing with such changes by specifying appropriate dependency version ranges.
If we start supporting legacy forever just because some other library or application specifies dependencies in a wrong way it would defeat the original purpose of Semantic Versioning.
We will therefore not start fixing other people's code by re-introducing technical debt.
"and all dependencies you are using "
even if one finds that they aren't doing this right in any deps, do you expect people to fork all these deps etc? :)
this is what i meant by idealistic concepts in another post on SO regarding this :)
yes, you can break things in major versions. in theory :) because you also expect here that people will use ranges in the according way. which in practical reality (unfortunately) is not the case.
We will therefore not start fixing other people's code by re-introducing technical debt.
i dont know what you mean by "technical debt" here. to me all this is just syntactical sugar for one or the other way to express a JS import honestly :D it's not really a feature of any library itfp i would say.
i get your point philosophicaly but i dont find it very pragmatic.
either way, i dont care what is done here. i already said that i found a solution to the problem for our case. i just wanted to help you with providing the data i posted before.
you dont need to come up with grand justifications for how you proceed on the matter.
even if one finds that they aren't doing this right in any deps, do you expect people to fork all these deps etc? :)
Realistically, it's probably only one package that accidentally used the wrong range. Should be as easy to fix that package with a PR, as sending a PR to this repo.
[...] because you also expect here that people will use ranges in the according way. which in practical reality (unfortunately) is not the case.
I think that this is a very very rare occurrence. Npm automatically uses the correct ranges when you run npm install, and I've never worked in a project that doesn't use ranges.
Are you really suggeting that no package on npm can ever make any breaking changes?
either way, i dont care what is done here. i already said that i found a solution to the problem for our case. i just wanted to help you with providing the data i posted before.
Something that would really help is seeing which package is actually broken. Could you run npm ls uuid and post the result here?