The AppVeyor failure seems to be an issue with the CI server not having access to a git repo. Can you have a look and re-trigger? ping @iarna

I'll have to check tonight to be sure, but just in case I forget: Are you sure the top level lifecycle scripts don't include the postinstall script? Because just like preinstall should happen before install, postinstall should happen afterwards...

Yes it does include the postinstall script but it also runs build before hand..

What I can do is refactor topLevelScripts into two methods pre/post and run them before/after executeActions and that should be valid.

@DenianArthurShades I did a slight refactor, as mentioned, and now runTopLevelLifecycles is split into pre and post methods and executed in the proper order. Please let me know if you're able to test this. Thanks!

@seldo @iarna can you have a look?

Added a simple test to verify that lifecycle scripts are executed in the proper order and that node_modules does not exist (on a clean install of an app) on preinstall task.

Thank you for putting this together. Unfortunately, this is, I believe, insufficient to the practical needs of a preinstall lifecycle. Specifically, my understanding is that some of the things folks want to be able to do include installing modules or otherwise modifying the tree before the installer starts. To do that, this needs to execute before the currentTree is loaded off disk, which is substantially earlier in the process.

@iarna ok what is required? Are we going off of what people want or some agreed upon spec?

I'll do whatever is necessary to get this bug fixed.

@iarna also with this PR I am still able to install modules in the preinstall step...

@iarna let me know your thoughts on this. I can take this further if necessary but thus far I think my PR works as expected.

I would really appreciate a more thorough explanation here as to why this isn't adequate for merging... I'm willing to put in the time to make adjustments but the one comment I've received thus far is fairly ambiguous and is questionable whether it's even necessary.

Last comment: I will just put this here that your own documentation says preinstall should only be used for compilation not for installing dependencies.. so I would really rather us not introduce feature creep into this and fix a bug that's existed the entire major version 3.

@palmerj3 Thank you for your patience. I don't disagree with you per se, but it's not exactly installs people want to do here. I believe the main desire is to be able to setup symlinks in the node_modules that npm will preserve. The reasons I outlined previously are my summation of previous issues around this. Fixing this as you have would solve some but not all of the concerns folks have raised about the current behavior.

That being said, as I've thought this through more I think I'm inclined to say "no" to the "can read the node_modules AFTER preinstall time" because while that works fine for applications, it would be a disaster to implement for things being installed as dependencies, and I'm not comfortable having those two modes work differently.

To solve that need, I would prefer to have some application lifecycles that don't apply when you're working with something as a dependency. But obviously that's out of scope for this.

So on reflection I think I am ok with this as it is. Uh, sorry for taking so long to come around on this. =D I have a few minor tweaks I'd like to see in this PR, but they're small enough I'm happy to make them at merge time.

@iarna ok cool! Let me know if you need me to make those changes.

This has been merged and will be in the next release (scheduled for later today).