Git Product home page Git Product logo

Comments (3)

jakebailey avatar jakebailey commented on June 3, 2024 2

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.

from tslib.

krinoid avatar krinoid commented on June 3, 2024

@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.)

from tslib.

jakebailey avatar jakebailey commented on June 3, 2024

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.

from tslib.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.