import.meta path helpers proposal

[GeoffreyBooth]

Resolves https://github.com/wintercg/proposal-common-minimum-api/issues/50. cc @mcollina @jasnell @Jarred-Sumner

[GeoffreyBooth]

@lucacasonato I know you said in #50 that Deno would be uninterested in implementing this API, but I’d appreciate your input on this just in case Deno’s opinion changes someday; ideally the spec we agree on is something that would work for Deno should the team decide to support import.meta path helpers at some point.

@Jarred-Sumner does Bun have any notes on this proposal?

[lucacasonato]

I am still strongly opposed to including this in the common minimum API, for the reasons I have elaborated in the issue this PR references.

Deno will not implement- it's not common minimum.

[GeoffreyBooth]

Deno will not implement- it’s not common minimum.

The proposal specifies that these properties would be optional for runtimes to implement if they wish: as in, if a runtime wants to provide import.meta properties representing the absolute path of a file: module, and the absolute path of the parent folder of that module, then these are the names to use and their semantics. So Deno can choose not to implement them, however if this proposal is accepted and someday the Deno project changes their position, then they would implement the properties using these names and these behaviors. That’s different than simply rejecting the proposal and each runtime doing as they wish; accepting this proposal would mean agreeing on a common standard even if that standard is opt-in.

[lucacasonato]

This is the common minimum API though. The maximum set of APIs supported across all compatible runtimes. If there are optional features not gated on capabilities of the runtime, but on implementer interest, it is by definition not a common minimum subset. It is then just a loose collection of recommendations and does not fulfil it's purpose. As such, this is the wrong place for this API because there is no consensus among implementers.

[jasnell]

This is the common minimum API though. The maximum set of APIs supported across all compatible runtimes. If there are optional features not gated on capabilities of the runtime, but on implementer interest, it is by definition not a common minimum subset

FWIW, this is why I had suggested this as a separate md file ( like the ALS subset ) for now rather than adding to the actual common minimum index.bs file, and we can always find a better home for it.

[jasnell]

I believe we can close this now that the PR landed over in the import.meta registry repo

[GeoffreyBooth]

Now that Node, Bun and Deno have all implemented this, should it become part of the common minimum?