Skip to content

Latest commit

 

History

History
81 lines (60 loc) · 4.63 KB

0007-js-package-manager.md

File metadata and controls

81 lines (60 loc) · 4.63 KB
Raw

JS package manager

  • Status: accepted
  • Deciders: Thomas GERBET, Joris MASSON
  • Date: 2021-09-29

Technical Story: request #23396 Use pnpm to replace npm and Lerna

Context and Problem Statement

Tuleap currently uses npm 7 and Lerna to install/update/delete dependencies of our packages and to build the JS-related code to something that can be consumed by end-users.

Tuleap is mostly organized with a mono-repo structure:

  • most of the code is located in one single repository containing the majority of the build instructions
  • the internal JS packages are divided into 3 categories:
    • the "libs" which are destined to be shared between multiple packages, they exist as a way to share code
    • the "apps" which are used to build front-end interfaces
    • some edge case situations where we use JS code to generate some backend code
  • the internal JS packages have dependencies between them (and of course also to JS packages that are not internal)

However, some Tuleap plugins are stored and managed in external repositories. Those plugins are expected to be put in the usual plugins/ directory but cannot be expected to always be present. In this split monorepo situation nothing in the main repository can be dependent on code or data located in one of those external repositories.

This structure presents challenges which forced us to adopt various, not pretty, hacks. The JS ecosystem has moved a lot since the last time we took a serious look, it might be time to revisit it.

Considered Options

Decision Outcome

Chosen option: migrate to pnpm because it comes out the best solution at the moment (see below).

The decision might and should be revisited in the future to see if it is still the best available option.

Pros and Cons of the Options

Keep using npm 7

  • Good, because it is the most common package manager in the JS community
  • Good, because it is already what we are using so nothing needs to be done
  • Bad, because we cannot use the workspace feature due to our "split monorepo":
    • we need to manually clean our internal dependencies from the lockfiles
    • we need to use Lerna to build the packages in topological order which seems overkill since we do not use or need any of the main features of the tools
  • Bad, because we are currently encountering a bug in the way one of the low-level part of npm works, which force us to workaround it

Migrate to Yarn Classic

  • Good, because it is one of the major JS package managers
  • Bad, because it does not come with a workspace feature so we will be forced to continue to also use Lerna
  • Bad, because it is currently in maintenance mode and as such not a good bet for the future
  • Bad, because we did not have a so good experience back in the days and it is still true that the performance is not really our main issue (and the diff with npm 7 is negligible at best)

Migrate to Yarn 2+ / Berry

  • Good, because it is one of the major JS package managers
  • Bad, because the workspace feature does not work so well for our structure which will force us to still edit the generated lockfiles and/or to still use Lerna

Migrate to pnpm

  • Good, because we can make the workspace feature work for our situation without hacks
  • Good, because we would not need to use Lerna anymore
  • Good, because the way the dependencies are installed leads to a stricter dependencies management
  • Good, because, while it is not our main pain points, it saves disk space and it is quite faster than npm to install all our dependencies
  • Bad, because it is less used than the other considered options. It is however gaining traction lately [0] [1] and is one of the three supported package managers of the recently introduced Corepack.