Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: relativize file links when inflating shrinkwrap #758

Closed
wants to merge 9 commits into from

Commits on Feb 3, 2020

  1. Configuration menu
    Copy the full SHA
    08dd4ad View commit details
    Browse the repository at this point in the history
  2. Configuration menu
    Copy the full SHA
    e453b41 View commit details
    Browse the repository at this point in the history

Commits on Feb 4, 2020

  1. Configuration menu
    Copy the full SHA
    1a893fc View commit details
    Browse the repository at this point in the history

Commits on Feb 5, 2020

  1. Configuration menu
    Copy the full SHA
    1b597b1 View commit details
    Browse the repository at this point in the history

Commits on Feb 14, 2020

  1. getRequested: look also at optDeps when determining package spec

    If the shrinkwrap code calls `getRequested` on an optional dependency,
    the `spec` passed to `npa.resolve` is null. `npa.resolve` then thinks
    it's a request `fromRegistry`, with spec defaulting to `latest`. And
    in case the real spec is a tarball, returns nonsensical result where
    `isRegistry` is true, `fetchSpec` is `1.0.0` instead of `file:...` and
    the record written to the shrinkwrap is wrong. It contains a `resolved`
    field, which should be used only for packages downloaded from the registry.
    jsnajdr committed Feb 14, 2020
    Configuration menu
    Copy the full SHA
    83358bc View commit details
    Browse the repository at this point in the history
  2. Configuration menu
    Copy the full SHA
    ce2936f View commit details
    Browse the repository at this point in the history

Commits on Feb 17, 2020

  1. Don't use tree.package._where when resolving shrinkwrap dependency

    The path in `sw.requires` is always relative to the requesting package
    location, and the default from `packageRelativePath(tree)` is always correct.
    
    For `type=file` dependencies, `tree.package._where` contains the `realpath`
    of the requesting tarball, which is the location where it was unpacked in
    `node_modules`. That's completely useless for resolving dependency paths.
    We're interested in the source location of the packed tarball. That's the path
    against which the dependency spec should be resolved.
    jsnajdr committed Feb 17, 2020
    Configuration menu
    Copy the full SHA
    b8a5e05 View commit details
    Browse the repository at this point in the history
  2. doesChildVersionMatch: take fetchSpec into account

    When comparing specs like `file:../b-1.0.0.tgz`, the `rawSpec` and `saveSpec`
    contain paths that are relative against different roots. We need to compare
    the `fetchSpec`, too, which is absolute.
    jsnajdr committed Feb 17, 2020
    Configuration menu
    Copy the full SHA
    3963e5a View commit details
    Browse the repository at this point in the history
  3. getRequested: don't use reqBy.realpath when resolving dependency paths

    `realpath` contains the location of the unpacked tarball, and that's useless when
    resolving relative dependency paths in `package.json`. For that resolution, the location
    of the packed tarball is important.
    jsnajdr committed Feb 17, 2020
    Configuration menu
    Copy the full SHA
    e8ab363 View commit details
    Browse the repository at this point in the history