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 bikeshed #10

Open
jamiebuilds opened this issue Nov 29, 2018 · 4 comments
Open

Syntax bikeshed #10

jamiebuilds opened this issue Nov 29, 2018 · 4 comments

Comments

@jamiebuilds
Copy link
Member

Just opening this cause it came up at TC39

asset identifier from "url"
import asset identifier from "url"
import ref identifier from "url"

I guess there's some complexity with asset x from y @sebmarkbage?

There's also the dynamic forms which may or may not be good enough:

import.meta.resolveUrl("url")
import.meta.resolve("url")
@sebmarkbage
Copy link
Collaborator

sebmarkbage commented Nov 29, 2018

I think that asset x from y could work but it needs a no-newline mechanism to distinguish it from asset; x; from; y;.

import.meta is really owned by the host environment so maybe a language level dynamic form should be import.resolve. But why use the term import in one case but not the other?

import ref ... vs import.ref(...) has a nice parity. However, I think I'm also ok just dropping the dynamic resolution completely and letting that be a host environment specific thing. Since it's not applicable to bundlers, type systems, optimizing compilers, it's not very portable anyway. It sends a clear signal that the language favors static specifiers (perhaps with some parameterization option). At that point, parity doesn't matter as much.

@ljharb
Copy link
Member

ljharb commented Nov 29, 2018

How is the dynamic one not applicable to bundlers?

@sebmarkbage
Copy link
Collaborator

Bundlers (and other tooling that requires static resolution) can’t support dynamic resolution fully anyway. So adding specific syntax for it doesn’t bring any further guarantees of portability than what already exists.

They may support some limited form but they can do that whether it is on import.meta or not.

Note that I’m not counting parameterized loading as fully dynamic. The kind that some bundlers support by (ab)using a subset of the dynamic syntax. We could possibly add a more first-class solution for that as discussed in #5.

@jamiebuilds
Copy link
Member Author

jamiebuilds commented Nov 29, 2018

To be more specific, bundlers artificially enforce static restraints on lots of dynamic syntax in ways that are not guaranteed by the language. Just so they can extract a string specifier from an AST (or type graph in some rare places?).

Worse, none of these tools handle the same dynamic syntaxes in the same ways. Webpack has some funky "convert inline expressions to regexes", Parcel supports things like navigator.serviceWorker.register('/sw-test/sw.js'), other tools only handle static imports, there's a bunch of Babel stuff that tries to handle dynamic code that gets inserted into dynamic importers/loaders/etc.

It would be really nice to eliminate all of this, and import.ref(expr) or whatever just moves it around a little.

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