-
Notifications
You must be signed in to change notification settings - Fork 12
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
Syntax bikeshedding: package:@std/<name> #30
Comments
For any namespaced choice, we'd want to claim it as a username on npm to prevent collisions (it's not a convention, the (personally, I'm not a fan of abbreviations and would prefer a different name regardless) |
Agreed that, if we use this syntax, we should do this according to npm and not just snatch it with a change in interpretation on "our end". If we choose something that really evokes the web platform/native built-in modules, then npm policy may help us with the transfer, but definitely what you say is the first step. It's unclear to me how "std" would be interpreted with respect to the policy if we wanted to push that way. |
what if instead of a // instead of
import { foo } from "@std/foo";
// use
import { foo } from foo; since these module identifiers are supposed to be urls that the broswer can fetch and execute, quoted/string module name doesn't make sense for something that's supposed to be part of the "standard" library |
@namespace/module
is a frequently used convention in the JS ecosystem. Could we use it for layered APIs?As an import specifier, it's not "taken" (i.e., it produces failure in the HTML module specifier resolution algorithm), as we still have time to tweak details in package-name-map, so we could make it "just work":
As a URL, we'd probably want the
package:
prefix, as@std/name
may already be interpreted as a relative URL. Thepackage:
prefix is already proposed, as it comes up for mapped packages in exactly the same way. A script tag to use a built-in module would look like this:This strategy might require a slight tweak to the fallback alternative based on package-name-map:
@std/<name>
would be permitted as a key in the package name map, but it could also be provided as a value of a mapping.The text was updated successfully, but these errors were encountered: