Should tslib be in peerDependencies or just dependencies when building a library?

[valerii15298]

I am building nodejs typescript library. What is the official recommendation of where to put tslib: peerDependencies or dependencies and why?

[jakebailey]

dependencies. If you are building a TS package and enable importHelpers, then tslib is a hard dependency and must be installed for those using your package, as though you had imported it yourself like any other library.

[krinoid]

@jakebailey Just to be clear, is this the official recommendation even in the monorepo context as well? Say I have a monorepo with 2 projects that are shipped to end-users: P1, P2 and libraries in the monorepo, used by those projects: L1, L2. Everything is written in TypeScript, libraries are not published in NPM, same TS/tslib version everywhere.

My approach so far has been:

• P1, P2 list tslib in dependencies
• L1, L2 list tslib in peerDependencies (and sometimes devDependencies, if the library has tests and is compiled independently in CI to run the tests)

Feels like this is similar to e.g. react or express in shared libraries — we need them in runtime, but it's the consuming package that needs to provide those peerDependencies. Otherwise (i.e. listing tslib in dependencies) might easily result in multiple copies of tslib in the bundle in the frontend code.

TL;DR: I think that it makes sense to keep tslib in peerDependencies when building a library (especially in the monorepo context, where you control all versions of TS etc.)

[jakebailey]

I don't think it makes more sense, no. My personal mental model of peer deps is "this package augments or plugs into this other package". Some package managers (like yarn) don't auto install peers, shifting the burden of installing them onto downstream users. But, ideally, no user should ever be able to observe that you're using tslib or not; it's just a choice when compiling the code to share the helpers. It may even be the case that some package needs one version, while another package needs a different one. If they are the same, package managers are smart enough to dedupe (and usually it's only a v1/v2 thing).

Of course, in your private monorepo, you are free to do whatever you want. You can control the versions and the package manager.