local dependencies have confusing edge cases

[othiym23]

(tapping in @dylang, because local dependencies were his contribution, and @timoxley, because linklocal forces the issue a bit)

@iarna and I figured out that local dependencies, as they're currently implemented, conflate

• when relative paths to local dependencies are used on the command line, when it makes the most sense to install them relative to the current working directory, and
• when local dependencies are saved in package.json, when you want them to be relative to directory in which the package.json file is stored.

npm's implementation doesn't make it easy to determine which execution path led to a given relative path, so @iarna resolved this by treating file: and ./relative/path paths differently to capture the two use cases.

Because npm i -S ../local/dependency normalizes the paths to file: URLs when saving them into package.json, this isn't generally an issue in npm. However, this is a subtle solution to the problem, and it may cover up other edge cases we haven't hit yet.

As I see it, there are a few alternatives open to us:

1. Do nothing; the current solution works well enough for those who rely on it (if @dylang and @timoxley agree with @iarna's solution, this is probably good enough for now).
2. Disallow relative paths? This was @isaacs's solution when I first outlined this problem to him, although we quickly agreed that limited the usefulness of local dependencies unacceptably.
3. Always normalize to absolute paths? This is a slightly less draconian version of 1.
4. Always interpret relative paths to be relative to the current working directory? This makes it exceedingly tough to nest local dependencies.
5. Always interpret relative paths to be relative to package.json? This is the most consistent, but it breaks a bunch of npm's existing tests, and is a breaking change to how installing from a path worked before this feature was added.

I'd like to get this worked out before people have invested a lot of time building builds or tooling around local dependencies.

[iarna]

I've actually come around on the current behavior. I think it pretty much works the way people expect, even if, when you dig in, the differences are initially surprising.

The one change I would make would be to ONLY allow file: urls in package.json files. Disallow straight path names in package.json files as they're confusing.

[othiym23]

The one change I would make would be to ONLY allow file: urls in package.json files. Disallow straight path names in package.json files as they're confusing.

This is a sensible rule, and if we decide it's what we want to do, we should modify read-package-json to make the presence of non-file: local paths a fast failure.

[timoxley]

Leaning towards "Disallow relative paths", or file: paths, just pick one, simplicity > flexibility.

Struggling to see sane use cases where I'd want a relative path in a package.json to install something different relative to the specific directory I'm in when doing an npm install.

Can someone describe some use cases that we're trying to enable/protect?

[timoxley]

npm install ../some/path --save should definitely install whatever the path points at relative to cwd, but the path saved in package.json should definitely be relative to the package.json.

Is this what we're discussing?

[timoxley]

I think most sane is "Always interpret paths in package.json to be relative to package.json, always interpret command-line paths as relative to cwd" That should keep tests from breaking and make package.json useful.

edit: updated

[othiym23]

Build checkout directory has three subdirectories a/, /b, and /c. b local-depends on a: "a": "file:../a". c local-depends on b: "b": "file:../b". You can move the build directory around without having to fix up any package.json files, and all three can be edited / updated as individual, independent packages on disk.

[othiym23]

@timoxley you're describing option one, which is one I like because it involves me doing nothing. I do like @iarna's suggestion of disallowing unprefixed paths in package.json. It's cleaner and also necessary to get the correct "relative to CWD for command-line / relative to package.json for package installs" semantics.

[timoxley]

Agree with that also.

[timoxley]

but, if going to disallow unprefixed, then why have a prefix at all as it's no longer useful information?