Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does this support globbing? #72

Closed
fatcerberus opened this issue Nov 6, 2018 · 4 comments
Closed

Does this support globbing? #72

fatcerberus opened this issue Nov 6, 2018 · 4 comments

Comments

@fatcerberus
Copy link

fatcerberus commented Nov 6, 2018

Skimming through the proposal, it seems the import map must include a mapping for each specifier used in the project. This works well enough for module systems revolving around a package manager, like the npm ecosystem, but my use case is somewhat unique.

I have a game engine, miniSphere, with its own sandboxed file system. Files in this system are referred to using designated prefixes, for example @/file.ext refers to a file in the same directory as the game's JSON manifest and $/file.ext refers to the directory containing the game's main JavaScript module.

I'm currently in the process of porting miniSphere's API to the Web: Oozaru, however module specifiers have proven to be a sticking point as Web browsers don't currently have any support for bare specifiers. So a path like $/module.js is parsed by the browser as a bare specifier and of course this doesn't work. In trying to find ways to make it work, I discovered this proposal--but it seems to require all specifiers to be known in advance, which isn't feasible for implementing a custom file system.

I understand that it's not feasible to implement a module resolution setup like Node's, where you check for different patterns of filenames to find a module, in a Web browser. I also understand the performance concerns underpinning the decision not to support calling into JS for each import (which does prevent me from virtualizing my file system for SPK packages, but I can live with that). However, it occurred to me that I could solve my problem if the import map only supported globbing, similar to the paths option in TypeScript's tsconfig.json, where you give it a base path and a set of glob patterns to match module specifiers against:

"baseUrl": "./lib",  // <-- naked specifiers, e.g. import from "moment", will look here
"paths": {
    "$/*": [ "../src/*" ],  // all paths relative to baseUrl
    "@/*": [ "../*" ]
}

Are there any plans to support something like this? I don't think I can (easily) implement my file system any other way.

@domenic
Copy link
Collaborator

domenic commented Nov 6, 2018

No, it does not support globbing. No current plans, although see #7.

@domenic domenic closed this as completed Nov 6, 2018
@fatcerberus
Copy link
Author

😢

@domenic
Copy link
Collaborator

domenic commented Nov 6, 2018

It seems you'd be able to accomplish your use case by just mapping the "packages" $ and @. See https://github.com/domenic/import-maps#packages-via-trailing-slashes .

@fatcerberus
Copy link
Author

Oh, I must have missed that bit - I didn't realize you could map partial specifiers. 😃

I think I must have gotten the wrong idea after I read a bit about how it was good that you had to declare all specifiers used in the program in advance... I can't find the relevant text now though. Maybe that was from before the proposal changed...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants