module: remove require('.') with NODE_PATH compatibilty

[silverwind]

This basically reverts #1363 and removes the hack in place for the unintended use case of require('.') used in conjunction with NODE_PATH.

I'd like to give users a few months to accustom to the deprecation, so it might not be a candidate for 2.0.0, but rather 3.0.0.

[domenic]

We should at the same time start emitting warnings whenever NODE_PATH is used.

[silverwind]

So the consensus is to remove NODE_PATH entirely? What's the reasoning behind this?

[bnoordhuis]

It's been deprecated for ages. Seeing how it negatively interacts with the module system, I don't think we want to carry it forward forever.

[rlidwka]

Honestly, I don't see any negative implications of the NODE_PATH itself. Yes, some people are misusing it, but it's not a good enough reason to remove this feature imho.

[silverwind]

What are the alternatives to NODE_PATH? Absolute require paths?

[silverwind]

Let's move the discussion to #1627

[Fishrock123]

I suggest we move this to like 4.0.0, since 3.0.0 seems like it should be soon according to v8.

[silverwind]

Yeah, if 3.0.0 lands in the next 2 months, I'll delay this (according to the 3 months policy suggested recently).

[Fishrock123]

See #1735 - it should (ideally for v8?) land this week..

(according to the 3 months policy suggested recently).

Where was that suggested? That was the original suggestion but doesn't really work when v8 breaks every 6 weeks.

[silverwind]

@Fishrock123 I was just lazily following #12, but I see, it's not decided yet.

[Fishrock123]

Should this still land in 3.0.0, or is it better we target 4.0.0?

[silverwind]

Moved to 4.0, given 3.0 is imminent.

[rvagg]

@nodejs/collaborators thoughts on this for 4.0.0? I'm leaning towards punting till 5.0.0 to avoid some of the pain of users upgrading from 0.10 and 0.12 straight to 4. This is just another pain point they would encounter and it doesn't seem necessary to rip this band-aid off right now.

[thefourtheye]

@rvagg You are correct. I think we can defer all the current semver-majors to 5.0.0.

[mscdex]

Moving it to 5.0.0 is fine with me.

[rvagg]

Moving to 5.0.0, feel free to disagree though

[silverwind]

👍 this way, at least the deprecation message will be visible for some time to new-time users.

[targos]

ping @silverwind
5.0.0 is close. This has to be retargeted to master if you still want to land it.

[silverwind]

5.0.0 is close

I thought we were doing a 4.2.0 next? Anyways, it's too early to land this.

[jasnell]

4.2.0 and 5.0.0 are on independent parallel tracks. 4.2.0 is the LTS off
the current v4.x stable while 5.0.0 will be a new stable branch.
On Oct 9, 2015 2:55 PM, "silverwind" [email protected] wrote:

5.0.0 is close

I thought we were doing a 4.2.0 next? Anyways, it's too early to land this.

—
Reply to this email directly or view it on GitHub
#1452 (comment).

[silverwind]

Alright, moving to 6.0.0 in this case.

[jasnell]

Fwiw... The 6.0.0 stable will be cut right around early April 2016.
On Oct 9, 2015 2:58 PM, "silverwind" [email protected] wrote:

Alright, moving to 6.0.0 in this case.

—
Reply to this email directly or view it on GitHub
#1452 (comment).

[silverwind]

Updated and targeted master: #3384