Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: nzbr/pnpm2nix-nzbr
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: main
Choose a base ref
...
head repository: mojotech/pnpm2nix-nzbr
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: main
Choose a head ref
Checking mergeability… Don’t worry, you can still create the pull request.
  • 4 commits
  • 1 file changed
  • 2 contributors

Commits on Feb 27, 2024

  1. Add argument for build specific environment

    It is likely that a user may want to specify environment variables
    during the build phase as well as during pnpm install. Add an argument
    for a build specific environment. This allows the user to avoid
    duplicating the environment between a configure or prebuild step and
    installEnv, by using something like:
    
    let
      sharedEnv = { ... };
      buildEnvOverrides = { ... };
      installEnvOverrides = { ... };
    in
      mkPnpmPackage {
        buildEnv = sharedEnv // buildEnvOverrides;
        installEnv = sharedEnv // installEnvOverrides;
        ...
      }
    iteratee committed Feb 27, 2024
    Copy the full SHA
    ccbd38a View commit details
  2. Add support for pnpm workspaces as single derivation

    Allow a caller to specify a workspace and a list of components rather
    than a single source directory. This allows for the building of pnpm
    monorepo projects with dependency links between the various projects and
    a single pnpm-lock.yaml for the whole workspace. Requires that the
    script has the same name in all components.
    
    The location of all of the per-component package.json files is
    overridable. A workspace project can still specify the location of the
    root package.json via packageJSON, as well as the components'
    package.json files via componentPackageJSONs. The list defaults to
    c/package.json for c in components.
    
    Similarly, the list of distDirs for the components is overridable. For a
    workspace, the distDirs are all subdirs of $out rather than dist
    becoming $out. The default list is c/dist for c in components. Allowing
    for override handles the case where one component is built by a
    different tool like next and produces a different directory like ".next"
    
    NB: Any "link:" dependencies will need to be recreated as a preBuild
    step. pnpm will create the symlinks during install, and nix removes them
    because when the node_modules derivation is built, they are dangling.
    
    Attempts to leave the non-workspace pnpm package support intact.
    iteratee committed Feb 27, 2024
    Copy the full SHA
    a17fd10 View commit details
  3. Add support for placing additional artifacts into the result.

    A user may want the node_modules and package artifacts as a part of the
    output in order to have a runnable build artifact without needing the
    node-modules derivation or the sources available. Add options to control
    additional copies as a part of the install.
    
    Simplify the values used in the derivation so that the conditional logic
    is almost all in the let rather than in the derivation body.
    
    Some of this change should probably rebased into the first commit.
    iteratee committed Feb 27, 2024
    Copy the full SHA
    71a9968 View commit details

Commits on Mar 4, 2024

  1. Merge pull request #1 from mojotech/kb/pnpm-workspace

    Add support for pnpm workspaces as single derivation
    iteratee authored Mar 4, 2024
    Copy the full SHA
    c3cfff8 View commit details
Loading