I can't figure out how to write a test for this. @othiym23, I'd love some guidance :-)

Create a directory tree that you can set as the prefix for an invocation of the CLI, point EDITOR at a simple Node script that verifies dirname(argv[2]) exists and sets its exit code accordingly, and write out a config file pointing at that prefix. Sort of convoluted, but it shouldn't be that tough to write. Thanks, Jordan!

Interesting, ok thanks, I'll give it a shot.

Did you make any headway with the tests for this? I've now fixed the test suite for Node 0.11.16 / io.js 1.1.0 (as far as I know).

No, I haven't made any headway yet. However, I still get failures on latest master in io.js - also many of the tests still take forever. See https://gist.github.com/ljharb/a3366c4a21398d52f6b0 for the 22 failures I get.

Have you tried running npm prune --prod && npm install? You may not have picked up the new version of npm-registry-mock. I have green tests on both OS X and a pretty much pristine Ubuntu vm that's only been used for testing, not development work, from a fresh clone of the npm source tree.

@othiym23 After rm -rf node_modules && npm install it seems to be the same problem. I suspect it's because I have a non-default install path (installed with nvm), and I have the "~" prefix in my npmrc, and things like that? I updated the gist with the output of the second run, and the errors are identical to the first one.

@othiym23 Not sure if you did anything or if I unbroke something, but as of 7eecbd6 all tests pass on master on io.js v1.1. Yay! I'll see if I can get this PR's test written today.

I updated the PR with this test attempt - but I'm still getting EACCES errors even with the fix applied. Some more guidance, if you have it, would be lovely :-)

@ljharb I cleaned up the test a bunch in https://gist.github.com/othiym23/faa31f03736c3a747c5a. There's a lot going on in that diff, so I included the full test as a standalone file. Here's a summary of the changes:

1. Didn't replace the env on the child process, because that was nuking PATH in the child npm process.
2. Gave the stub editor a shebang line (should be installing that as a shim for Windows support, but the tests are pretty lax about this right now and so is not a blocker for landing the test / patch).
3. Made the stub editor executable.
4. Pulled the stub editor out of test/ and into an inline fixture in the script (using the neat multiline comment hack that @isaacs reminded me about).
5. Ran everything in a directory created and destroyed by the test case itself, following existing practice from the rest of the tests (BTW, if you want to use $TMPDIR in a way that will be portable across Node versions, use osenv instead of os).

I think that's probably good enough to land, so if you want, I can land that, or you can update the PR with whatever tweaks you want to make. Thanks for your patience!

Thanks, this is perfect! I added your commit to the PR and updated it.

Finally landed as 6fd0fbd, rebased and squashed, with a few small tweaks to the test to make it more robust. Thanks for the fix and your patience, Jordan!

Yay, thanks! :-D

@othiym23 @ljharb

I think this change does not work as intended. If I run npm install --prefix=. it creates an etc folder in my CWD. If I run npm install --prefix=./client it will create an etc folder in my client folder.

We might have to only mkdirp the etc folder if the global flag is set.

See uber-archive/npm-shrinkwrap#74

Oops, that's clearly something I failed to consider. I'll take a crack at it today but please don't let that slow anyone else from fixing it sooner.

The change should probably be to move the creation of the containing etc/ subdirectory to immediately prior to writing the config file to the directory. When I first saw that pattern used elsewhere in npm, it felt kinda janky to me, but now I see that situations like this are exactly why it exists.

@ljharb any progress on this?

None yet. I'll try to make time this week.

@ljharb Cool; I might look into it if I get a moment later this week; i'll let you know if I do.

@ljharb @Raynos any updates on this?

Also seeing this issue when using the prefix argument. etc folders are flooding my directories anywhere an npm package gets installed. These folders are empty and harmless but they are kind of an eyesore to see everywhere an npm install is executed with a prefix set.

I also see the issue when use --prefix on npm install... any news about that?

Same here. Empty path/etc gets created with --prefix path. Maybe create it iff there's something to write in it?

Same here any fix on this? Appears when I run npm install with the --prefix flag from a different directory. But doesn't appear when I run npm install in the project root.

+1 @finetimi this is exactly what is happening with me right now.

@othiym23 @Raynos @ljharb The etc folders are still an issue, can we get this reopened, or another opened in its place for a fix?

As justechn says..

npm i --prefix src . 
ls src 

yields:
etc node_modules