-
Notifications
You must be signed in to change notification settings - Fork 26
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
Change keyword «with» #3
Comments
I don't see any problems with const foo = import('module', { type: 'json', anotherOption: 42 }) than, how should static modules syntax look like? import foo from 'module' with type: 'json', otherOption: 42; // ?
import foo from 'module' with type: 'json', with otherOption: 42; // ? I'd prefer something like import foo from 'module' with { type: 'json', anotherOption: 42 } |
I don't feel strongly about @inoyakaigor import module from 'module' as 'json' is more concise, but doesn't allow arbitrary attributes on the ImportDeclaration. This proposal will support more features than the type in the future. @chicoxyzzy import foo from 'module' with { type: 'json', anotherOption: process.argv } I think adding a new syntax would remove that confusion. Or is this something we would like to allow? |
An issue with |
object literals as xtuc posted is not possible because you'd have to evaluate a module to know if it shouldn't be evaluated. We could use object syntax with only literals or something, but that seems confusing. I'd imagined something like
|
@devsnek Yeah, that's what I'd imagine too. To me, the curly braces make me feel like you could use any expression there, which you can't. |
I'm proposing that Would this be too many separate meaning? |
in this statement import 'module' with type: 'json';
|
In the hypothetical situation with a bunch of options when the import string becomes too long curly brackets also look better IMHO import 'module' with
type: 'json',
anotherOption: 6 * 7, // should that be allowed?
...
lastOption: 'hello' + 'world'; // should that be allowed? vs import 'module' with {
type: 'json',
anotherOption: 42_000n, // should that be allowed?
...
lastOption: `hello ${'world'}`, // should that be allowed?
} |
the exact grammar should be entirely primitive literals |
so import 'module' with something: Symbol(); should be a valid grammar too? |
@chicoxyzzy that's not a primitive literal, that's a call expression. |
Oh, right. In that case, my only concern is that since import 'module' with
type: 'json',
anotherOption: 42n,
...
lastOption: 'hello world'; and import 'module' with {
type: 'json',
anotherOption: 42n,
...
lastOption: 'hello world',
}; Though, curly braces option looks better and could allow trailing comma. |
Also those limitations look very similar to |
Maybe it's even better to use record syntax there import 'module' with {|
type: 'json',
anotherOption: 42n,
...
lastOption: 'hello world',
|}; |
Records also allow nested expressions in them, so they don't really get us any closer... Literal strings which are not expressions in import statements is an established concept--that's what module specifiers are. They are sort of part of the bare minimum of what we need here to make the syntax work at all. So I'd suggest using literal strings and not other expression-like constructs. |
actually this gets me wondering about |
Disregard my suggestion about |
Overloading like that collides with the intended semantics of URI fragment components ("indirect identification of a secondary resource by reference to a primary resource and additional identifying information"). |
posted something here but probably belongs here as well for completeness? Parsing of the attributes could be left to hosts/compilers. For instance through querystring parsing. import json from "./foo.json" as "type=json&anotherOption=42";
// and default behavior
import json from "./foo.json" as "json";
// would be equivalent to
import json from "./foo.json" as "type=json"; |
Yeah, let's go with |
Have to say I agree with @chicoxyzzy The And the first part Currently if you have multiple attributes the syntax just gets a bit hard/confusing to read It's like an implicit "object"™ |
Keyword should be more explicit than "with", a cleaner syntax may be "if" as we are using simple conditions to see if the module gets loaded or not:
Multiple attributes should use curly braces like:
This allows for more options to be implemented in a not so far future. |
We can use import foo from './foo.json' when {type: 'json'} import foo from './foo.json' when {type: 'json', anotherOption: 42} |
I don't think either |
@justinfagnani Could you explain a little bit more the reasoning behind your comment? |
As @justinfagnani mentioned using |
#72 says it is indeed conditional. Is the behavior like that |
When it's not JSON, the module graph fails to load. The conditionality is about whether it should all fail or not. |
|
When the condition does not match, the module importing it fails to load. So, it's more of an assertion. |
Another option I haven't seen mentioned — prompted by the previous comment — is
In contrast to |
I dislike flogging a dead horse, but I want to emphasise that, to some developers,
While, for many developers,
|
Just adding my opinion here (for what it's worth) to say that However, if I may push back further,
At the end of the day, the motivation for the developer to use this feature (in this case) is because they want a file/resource interpreted by the engine/runtime as <type>, regardless of what the exact semantics are (if that weren't true, the extra syntax wouldn't be necessary in the first place). It therefore breaks expectations somewhat to have to say "ensure this file is <type>", because it doesn't inherently convey the sense (to me anyway) that I'm asking the engine to change its interpretation behaviour. Edit: I phrased that really badly/inaccurately but will leave it for posterity. With that in mind, and noting that it doesn't seem like a good idea to compromise accurate semantics in the general case, would it be totally out of the question to make type, assuming it will be the most common application of this proposal, a special case in the interest of ergonomics? e.g:
One of the reasons I bring this up is because I get the sense that if Just my 2c. |
I may have misunderstood, but I thought the engine/runtime is responsible for determining how to interpret the file/resource (e.g. via file extension or Content-Type header). Previously the proposed keyword was
Please correct me if any aspect of my understanding is wrong or misleadingly incomplete. I'm currently unclear if it is possible to unsafely import a JSON resource (e.g. with |
I'll try to explain better where I'm coming from. Here's a quote from the readme:
From my dumb, simplified, practical point of view this means:
Even though unsimplified it's more like (forgive me if I get something wrong):
This reveals that "extra syntax = JSON imports will work" isn't necessarily true, but my focus is not on the exceptional case - indeed I would expect that if there is some discrepancy with the source type (or any other easily detectable security vulnerability) an exception would be thrown; the keyword is almost irrelevant. One way I could maybe phrase this to get the point across is that the naming of Consider also that a dev is (generally) not going to be concerned if they included the extra syntax redundantly because the host/runtime/implementation (whatever the terminology is) didn't require it, but they will obviously take note if they don't include the syntax and it doesn't work. In that situation, how can you help but associate capability with the syntax? In essence, the
|
My apologies for misunderstanding your point, and thank you for the quote from the readme.
I don't think One of
could desugar to either
For this to work, One drawback is some developers might incorrectly assume this syntactic sugar would be extended for other assertions that may be specified in future proposals. Consistency with dynamic imports would also have to be considered. Complexity of the specification, documentation, runtime engines, build tools, and static analysis tools would increase. |
Although probably well known to others, it has just occurred to me
I don't know what proportion of JavaScript developers are familiar with SQL, but it might be interesting to explore the parallels, between This similarity suggests |
Thanks for your input @Andrew-Cottrell and @noinkling, we have a PR to switch the if keyword to assert: #80 . We are looking to discuss it during the next TC39 meeting (next week). |
PR was merged, we are now using the |
Has import foo from "source" while {type: "json"}; We already use the keyword in a similar context for JavaScript: do { this } while { predicate };
English: "do (this) for as long as (predicate) remains true."
JavaScript: import foo from "source" while { assertions };
English: "import (foo) from (source) as long as (assertions) are all correct."
JavaScript: import foo from "source" assert { predicate };
English: "import (foo) from source and assert that content
we haven't even loaded yet satisfies (predicate)" I'm probably just too attached to the idiomatic flow of our current syntax, which is currently well-formed English that reads quite nicely. |
To me, |
Yeah, I know... 😞 Stupid English doesn't have a shorter way to write import foo from "source" expecting {type: "json"}; |
|
Also, how many things—other than content-type—will realistically need asserting? The proposal says:
The only other thing I could see being asserted is file integrity, but come on, nobody wants to see this: import foo from "bar" assert {
hash: "sha512-nne9/IiQ/hzIhY6pdDnbBtz7DjPTKrY00P/zvPSm5pOFkl6xuGrGnXn/VtTNNfNtAfZ9/1RtehkszU9qcTii0Q=="
} Moreover, [true]
{
content: "Bar";
} What happens when I doubt this problem will crop up today (especially with the small number of formats we're concerned with), but who knows what we might be |
@Alhadis Well, the semantics are to assert that the content satisfies the predicate. This makes me glad you have this interpretation. |
I saw a few other languages use the -ing form of verb to modify import statements, so I am surprised that the keyword “ Examples from other languages:
|
After some back and forth, and after almost settling on import { x } from "foo" with { attributeKey: "attributeValue" } Thanks everyone for taking part in the discussion! |
Keyword
with
already exists. Maybe better define MIME type like this:import module from 'module' as 'json'
?The text was updated successfully, but these errors were encountered: