Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Fixed @types/ dependencies cause duplication on install
See original GitHub issueCurrently the versions for the types dependencies are pinned to specific versions (e.g. https://github.com/buildo/react-autosize-textarea/blob/master/package.json#L75)
This is problematic for consumers that want @types/ packages deduped. Would it be possible to switch the versions to using ^ modifiers?
Issue Analytics
- State:
- Created 6 years ago
- Reactions:1
- Comments:8 (5 by maintainers)
Top Results From Across the Web
How to fix NPM link duplicate dependencies issues
Dealing with dependencies when developing a package and using it through npm link.
Read more >Why does NPM's policy of duplicated dependencies work?
I think the first and foremost reason is that the language provides a common basis for primitive types (Number, String, Bool, Null, Undefined)...
Read more >Remove Duplicate Dependencies with Maven - Baeldung
Learn how to detect duplicate dependencies in Maven using the mvn dependency:tree and mvn dependency:analyze-duplicate commands.
Read more >Finding and fixing duplicates in webpack with Inspectpack
Needlessly duplicated dependencies produce larger, slower web applications. Let's embark on a deep dive into how npm and webpack work, ...
Read more >Duplicate library dependency after version change
The problem is that it wont remove the previous version, leaving both the versions there. This is causing bad class resolution (I think)....
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
My understanding is that
@typesdoes have a policy of semver, though it’s implementation relies on contributors adhering to that policy and bumping versions appropriately (just like any project following semver). Hearing that your understanding is that@typesdoes not follow semver is very surprising and concerning.Just to clarify — do you mean that you don’t understand
@typesto have a policy of semver, or that in practice you find that the policy is violated too often? I’d love to understand more about this, if you’re able to point me to any further information that would be greatly appreciated.In my project I currently have
@types/react16.0.25, and after I add react-autosize-textarea (that depends on@types/react16.0.30) and try to compile the project, I get the following errors:My options are:
--skipLibCheck— not really acceptable as I have my own.d.tsfiles that should be checked.@typesdependencies (so as to dedupe), and raise issues and pull requests to bump to new versions of@typespackages (as they come out) to keep them all in lock-step with each other.@typesdependencies.@typesdependencies to use^instead (current approach).^@typesversions.I suspect the reason that
@types/xis included in your package.json is because it’s recommended in the TypeScript handbook:Here’s my thoughts on this situation:
We know that TypeScript’s JSX types are global, and that if multiple versions of
@types/reactare installed they’ll likely conflict, so we don’t want to permit that. The most correct solution here is probably to usepeerDependencieswith a fuzzy version of@types/react(e.g.^16.0.0) so that consumers are responsible for providing it if needed.When someone installs the library (that does not yet have
@types/reactinstalled) they will get a warning from NPM telling them it is missing.This is great for TypeScript consumers, but would be annoying for non-TypeScript consumers because they have no reason to install
@types/x, yet unless they do they will be plagued with NPM warnings every time theynpm install. NPM does not offer an alternative that both prevents incompatible adjacent@types/xversions, whilst not throwing a warning on install if it’s missing, whilst also guaranteeing de-duping.The solution that other packages have taken with
@types/react(i.e. exclude it from dependencies) is probably the most pragmatic one for libraries that have both TypeScript and non-TypeScript consumers, as any TS consumer is already going to have React types installed, and non-TS consumer won’t get a warning.@types/reactis a bit special though, in that it’s generally incompatible with other versions of itself. The conclusion above does not apply to all@types/packages. In general you should follow the TS handbook and include@types/dependencies inpkg.dependencies, using the fuzzy version^prefix to give consumers a balanced compromise of de-duping and safety.Ultimately avoiding breakages when new package versions are published can only be solved by consumers using lock files in the CI. (more on that below)
Thanks for the link, reading it was helpful for me to understand your position. Here’s my take on it:
The fundamental problem is that the author has misguided belief that semantic versioning precisely describes program behaviour and can be relied upon to be “truthful”. There’s a few ways that’s flawed:
numbertonumber | stringa breaking change?) — all of these could break downstream codeThe author comes close to the solution here, and even mentions lockfiles (this is the solution) but ends at the wrong conclusion of pinning versions being ample (hopefully he means for his own projects, and not a recommendation to other developers, though this distinction is not made clear in the article).
Pinning versions is a weak solution here, as it does nothing to protect you from fuzzy transitive dependencies, e.g.
You depend on
foo@1.0.0, butfoodepends onbar@^2.0.0. This means that whilenpm installwill always give youfoo1.0.0, there is no guarantee you’ll get the same version ofbarevery time.The real solution here is to use lock files as they pin the versions of the entire dependency tree (this includes all transitive dependencies).
To upgrade packages you do it on a branch and update the lock file with a new set of dependencies, check it passes your test suite, then merge to your main branch.