search

drufball / layered-apis

A new standards effort for collaborating on high-level features.
275 stars 12 forks source link

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

Open littledan opened 6 years ago

littledan commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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