Proposal for transparent interop implementation

[GeoffreyBooth]

This is a proposal based off of #82 (comment). I’m writing it as a pull request so that I can revise it based on feedback, and so that people can comment on particular parts of it; I don’t expect this to get approved or merged in. This also isn’t meant to be the proposal; I think the approach currently being pursued by @MylesBorins and others holds a lot of promise, and this isn’t meant to criticize that. This is just another idea, for another implementation that could be pursued in parallel.

[bmeck]

Is this a proposal or just comments on various things? I don't see any explanation of how we implement these comments.

[GeoffreyBooth]

@bmeck It’s a proposal for an implementation, and a work-in-progress one at that. That said, the code for some of these already exists in various implementations that are out there, such as experimental-modules and the NPM one.

[bmeck]

@GeoffreyBooth I think moving it to passive voice would help me understand what is proposed vs what is commentary. As it is read right now there seems to be a lot of personal commentary being used as a proposal mechanism, which leads to confusion since it would apply to only yourself when trying to read something as a specification, not to the implementation / people using your proposal. I tried to re-read it to make comments but will probably need to go over it again a few more times to discern what is commentary vs what is not.

[GeoffreyBooth]

@bmeck I’ll take another pass at this more in the passive voice. I was often writing in the first person, what sounds like commentary, because so many of these calls of how I’d like the user experience to be are inherently subjective, and I’m trying to avoid discord by making it clear that I speak only for myself. Even with that, obviously, some people took offense. I’m not sure how to suggest alternatives to experimental-modules without drawing ire.

This isn’t a detailed plan for an implementation that I plan to build myself, nor am I really prepared to write something so detailed as that. I’m not a Node contributor, and I obviously don’t have the level of familiarity that many of you do. I need help fleshing this out to make it viable; I can’t defend it against every edge case people come up with. I’m writing this as a user describing the user experience I hope to get out of Node’s modules implementation.

Many, if not most, of the features that people have requested concern “transparent interoperability” in various definitions and permutations. This document is an attempt to try to describe an implementation that covers as many of those features as possible. I’m not terribly attached to anything you see here, other than that I want to push things in the direction of “transparent” whenever possible (and I don’t consider .mjs transparent, which is the defining implementation detail difference between this/NPM/@zenparsing/Defense of .js and experimental-modules). I’m hoping that some of the folks pushing for transparent interop features can help flesh this out with suggestions for how to achieve the features they’re requesting, especially features that aren’t already covered by experimental-modules. Even if the eventual implementation of a particular part of some feature gets split out into a loader, it would be good to hash out how it could be implemented, wherever that code happens to end up.