Now that this is implemented in Node.js --experimental-modules we should be able to support package.json "exports". Once we have "aliases", we should be able to deprecate "map" for "exports" and "aliases".

One hard thing will be supporting the "browser" field properly under this model. It's still debateable whether the "browser" field object form should support mapping modules if we have differential exports and aliases. Perhaps "map" can remain the greater abstraction, or perhaps we can directly unify on a "browser" desugar into aliasing and exports.

Rather just handle URL space as a encodeURI step at the end to store in the registry.

This will improve performance, as with cases like relative maps we end up encoding and decoding URIs multiple times which is just plain silly.

resolve('./x//y') should resolve into ./x/y.

Then again looking at the documentation for Node.js, it was recently renamed from "cjs" to "commonjs". I guess jspm-resolve is ahead of its time 😀

Could be related with #10 .
Following is a simple reproduction
https://github.com/fusionstrings/jspm-resolve-test
https://glitch.com/~jspm-resolve-test

Here https://github.com/fusionstrings/jspm-resolve-test/blob/master/test.js I am trying to get resolved module type and despite being package.json.type : "module", /module.js is resolving to commonjs and missing module is not throwing error.

Based on my understanding is type is set to "module" it should resolve to js files as module.

For the async case, the cache should be awaited on, with promises stored in it.

Map configuration should be verified according to the rules in the apply_map spec. This verifyMap function could either be applied in the main resolver after packageResolve, or it could be delegated to packageResolve. verifyMap should be shared as a lib if delegated, otherwise at least hookable for the exception cases.

This seems a bad idea in retrospect, would be better to leave to be handled externally again, and remove this.

Would be nice to be able to abstract from fs with a custom fileExists hook.

It would be useful for eg TypeScript workflows to be able to add custom extensions to the list through a resolver option.

For example to extend with .ts, .tsx, d.ts, .js, and .jsx.

It's worth also considering if TypeScript precedence before js would be important here or not.

Now that this is properly supported in --experimental-modules, we should support it in jspm resolver fallback paths too.