How would deep imports be handled? about import-maps

[justinfagnani]

Currently everything after the package name is a path internal to the package, so you have to include the full filename:

import { map, filter, mergeMap } from 'rxjs/operators/index.js';

Or, you can define another nested package:

{
  "packages": {
    "rxjs": {
      "path": "rxjs",
      "main" : "index.js"
    },
    "rxjs/operators": {
      "path": "rxjs/operators",
      "main": "index.js"
    }
  }
}

Packages defined in the map do not have to correspond to npm packages.

[benjamn]

Think about packages like @babel/runtime, where you're always supposed to import a nested path (since there isn't a main entry point for the whole package). I'm hoping we can avoid listing out every single (sub-)subdirectory and module in packages like that.

[justinfagnani]

Ok, thanks for clarifying. This is already the case.

Once you define the path for @babel/runtime everything after the package name in a specifier is just a path in the package folder. The configuration you gave works.

[MylesBorins]

The current best practices are for common.js We do have the ability to revisit some of those choices and set a new baseline with esm. I'm planning to bring a proposal to adopt this mechanism and changes to resolution of in the node esm implementation when we get there

…

On Sat, Mar 17, 2018, 2:35 PM Jordan Harband ***@***.***> wrote: @justinfagnani <https://github.com/justinfagnani> it's not about "short", it's about "compatible with existing best practices in the npm ecosystem", which are to always omit the extension in require/import paths. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#16 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecV2LneS9Vz-pfRk07ck-leje4YGzoks5tfVeNgaJpZM4SuEKm> .

[benlesh]

wouldn't that be:

{
  "packages": {
    "rxjs": {
      "path": "rxjs",
      "main" : "index.js"
    },
    "rxjs/operators": {
      "path": "rxjs/operators",
      "main": "operators/index.js"
    }
  }
}

?

[justinfagnani]

No, because the value of main is joined to the package path.

Also, if we add a shorthand form that contains both path and main in a single string, we might be able to write:

{
  "packages": {
    "rxjs": {
      "path": "rxjs",
      "main" : "index.js"
    },
    "rxjs/operators": "rxjs/operators/index.js",
  }
}

But I'm unsure how this would work if you also wanted to allow access to other modules within rxjs/operators, like rxjs/operators/first.js. We haven't talked about the short form implying a path mapping for the dirname of the main file.

[benlesh]

Cool.. I'm satisfied with that answer... but it sounds like there are still some open questions. Do you want me to leave this issue open?

[justinfagnani]

Yeah, leave it open so we can add an example of this.

[benjamn]

If you were willing to write

import { map, filter, mergeMap } from 'rxjs/operators/index.js'

then hopefully there would be no need to include rxjs/operators in the package map explicitly, since the existing entry for rxjs could be used to interpret the rxjs/operators/index.js identifier, by looking up the path of rxjs and then path-joining operators/index.js to it?

In other words, is it accurate to say that including rxjs/operators in the map is only necessary because you want to specify a default index.js to be appended to rxjs/operators?

[ljharb]

I’d certainly say that’s an important use case, since it’s the convention used in most npm packages (omitting extensions and relying on directory searching). By allowing these to be precomputed into a package map, then code wouldn’t need to be modified to run in a browser.

[justinfagnani]

What's the problem with requiring file extensions?

@babel/runtime/helpers/toArray just isn't much shorter than @babel/runtime/helpers/toArray.js

[benjamn]

I am totally in favor of requiring file extensions!

What I want to avoid is having to list out every single @babel/runtime/helpers/... bare identifier in the package map. Hopefully you could just say

{
  "packages": {
    "@babel/runtime": {
      "path": "/path/to/@babel/runtime"
    }
  }
}

and that would be enough to make import "@babel/runtime/helpers/toArray.js" work without explicitly saying anything about the helpers subdirectory or its contents in the package map.

[ljharb]

@justinfagnani it's not about "short", it's about "compatible with existing best practices in the npm ecosystem", which are to always omit the extension in require/import paths.

[ljharb]

@MylesBorins the current best practices are for "i want my require/import to be more robust against refactoring", and ESM, WASM, etc, will add "robust against changing of the module format, where possible". I think abandoning that resolution mechanism in node would be a terrible idea, but we can discuss that in the appropriate venue.

[ggoodman]

Are there an explicit specificity-resolution semantics that should be discussed in the proposal?

In the context of original question, do we have an algorithm for determining which top-level package entry should be chosen?

  "packages": {
    "rxjs": {
      "path": "rxjs",
      "main" : "index.js"
    },
    "rxjs/operators": {
      "path": "rxjs/operators",
      "main": "index.js"
    }
  }
}

Intuitively, we know that the latter should be used for rxjs/operators but I don't think I saw anything that states this explicitly.

Consider the example of import { flatSmoosh } from 'rxjs/operators/flatSmoosh';; the top-level package specifier chosen should be the most specific one, I think.

[domenic]

The proposal has changed a lot, so let me close this; if it's still unclear in the new proposal let me know.

Concretely, the answers are still fairly similar, but things are a bit less verbose.