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

Syntax bikeshedding: package:@std/<name> #30

Open
littledan opened this issue Jun 20, 2018 · 3 comments
Open

Syntax bikeshedding: package:@std/<name> #30

littledan opened this issue Jun 20, 2018 · 3 comments

Comments

@littledan
Copy link

littledan commented Jun 20, 2018

@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":

from "@std/foo" import { bar }

As a URL, we'd probably want the package: prefix, as @std/name may already be interpreted as a relative URL. The package: 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:

<script type="module" src="package:@std/virtual-scroller"></script>

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.

@ljharb
Copy link

ljharb commented Jun 20, 2018

For any namespaced choice, we'd want to claim it as a username on npm to prevent collisions (it's not a convention, the @namespace always represents a concrete user on npmjs.com). For https://npmjs.com/~std specifically, we'd need to ask the current owner if they're willing to hand it over, and if not, pick a different name.

(personally, I'm not a fan of abbreviations and would prefer a different name regardless)

@littledan
Copy link
Author

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.

@obedm503
Copy link

obedm503 commented Sep 7, 2018

what if instead of a @namespace to precede standard modules, we dropped the string identifier and made it syntax

// 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

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

3 participants