Comments (12)
@MylesBorins maybe my intent was lost... all these modules are modules, but I assume the suggestion here is about modules authored as source text ecmascript modules. type: module
seems like a tautology to me, all modules are modules.
from proposal-import-attributes.
I want to suggest: we can come back and add this between Stage 2 and 3 (or even later, after initially shipping, why not), but that we don't need type: "js"
for a basic proposal when assessing coherence/viability of it. So I think coming to a conclusion on this question blocks Stage 3, but not Stage 2.
from proposal-import-attributes.
I'd suggest omitting this. We will have to support the case where no type is specified. Is there really that significant of a benefit to include multiple ways to spell this case?
(The type: "module"
suggestion seems pretty confusing to me, since all of these things are modules... The notion of type
here does not correspond to classic/script vs module. I'd prefer type: "js"
or type: "javascript"
if we include one of these.)
from proposal-import-attributes.
There's the additional piece that Ecma doesn't own the copyright to the word "javascript" and I'm not sure if we'd be able to encode that in the spec.
from proposal-import-attributes.
type: 'source-text-module'
perhaps, but not type: 'js'
from proposal-import-attributes.
from proposal-import-attributes.
Allowing a "js" type may simplify the code generation work
from proposal-import-attributes.
If an enviroment would want to only load modules with a type
attribute we need to allow JS, however I'm not convienced that developers would use it if not necessary.
from proposal-import-attributes.
I imagine people would want to use it in dynamic imports just for completeness e.g.:
const types = {
".js": "js",
".wasm": "webassembly",
".json": "json",
".html": "html",
}
const module = await import(url, { if: { type: types[getExtension(url)] } });
from proposal-import-attributes.
"type": "javascript"
is currently not implemented in Chrome. While a missing type is treated as JS equivalent in the spec, I think it would be useful to have further implementation guidance from the spec if hosts are expected to implement this type or not, which also relates to the JS / WebAssembly assertion discussion. If guidance is still unclear here then that should also be clarified in the spec.
from proposal-import-attributes.
If guidance is still unclear here then that should also be clarified in the spec.
In #114 I suggested that the proposal include type: 'javascript'
to align with the HTML spec. Basically, the lack of an assertion type implies type: 'javascript'
, and cannot imply any other type.
from proposal-import-attributes.
That's not what was discussed in plenary, where consensus (as i recall) was to allow hosts to make any number of optional types that can mean the same thing as "no assertion".
from proposal-import-attributes.
Related Issues (20)
- Examples? HOT 2
- HTML integration compatibility with assertion invariant HOT 28
- Broken references in import assertions
- There should be an escape hatch to allow unknown import attributes HOT 3
- Tracking feasibility of unshipping `assert` contextual keyword in Chrome HOT 8
- No need for NLTH with `with` keyword HOT 9
- Stage 3 reviews HOT 15
- Inferring module type from MIME type vs `type` attribute needs clarification HOT 7
- Changes due to stage 3 reviews to present in July 2023 HOT 2
- return of dynamic import() HOT 1
- Invalid attributes keys in static imports should be a resolution/loading error and not a parsing error HOT 5
- Consider restricting attribute keys syntax to identifiers and strings again HOT 12
- Adding WPT tests HOT 2
- Restrict generalization by scoping private keys HOT 2
- how to use this feature in browser without polyfil? HOT 5
- Support gating with Progressive Enhancement or Graceful Degredation HOT 4
- Importing arbitrary files as raw bytes HOT 1
- Trouble with JSON Imports in JavaScript HOT 4
- [spam]
- [spam] HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from proposal-import-attributes.