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
module-types use assert type to detect module type #2434
base: main
Are you sure you want to change the base?
Conversation
xref #2432 |
File size impactMerging module-types into main will impact 7 files in 3 groups. browser (2/2)
node (1/1)
extras (4/8)
|
Unfortunately, this is not how assertions are supposed to work - the content-type header is supposed to be the authoritative source for the module type information, not the assertion. https://github.com/tc39/proposal-import-assertions#proposed-semantics-and-interoperability |
Now module-types will do the assert, but can fallback to given type if mime is acceptable based on https://github.com/tc39/proposal-import-assertions/blob/master/content-type-vs-file-extension.md , do you thinks is this ok ? this pr need #2435 |
Unfortunately the assertion can only be a validation and cannot affect the way we do fetching. |
aa88e31
to
4e6cdd1
Compare
@guybedford changed throw to a warning log, is this ok ? |
} | ||
|
||
var fetch = systemJSPrototype.fetch; | ||
systemJSPrototype.fetch = function (url, options) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I missed that we were passing the assertion directly as options
here. Does that mean that you can set custom fetch options this way as well via the new System.register attributes?
var mime = res.headers.get('content-type'); | ||
var contentType | ||
for (var i = 0; i < contentTypes.length; i++) { | ||
var rule = contentTypes[i]; | ||
if (rule[0].test(mime)) { | ||
contentType = rule[1] | ||
break | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if there's a shorter way to do this?
if (assertType && contentType){ | ||
if(contentType === fallback){ | ||
contentType = assertType | ||
} | ||
if (assertType !== contentType){ | ||
console.warn(process.env.SYSTEM_PRODUCTION ? errMsg('W7') : errMsg('W7', `Module ${url} has an unexpected content type of "${mime}": expected module type ${assertType} got ${contentType}.`)); | ||
contentType = undefined | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems fine to me, just watch the spacing of the syntax. Also shorter code is always better for this lib!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we can add this, let's just clarify how we are exposing the fetch options to the assertions system? Does that mean System.register([], () => {...}, [{ headers: { ... } }])
can eg customize fetch options?
@guybedford Passing header is possible, but should or shouldn't is a question, for me, the |
BTW, for hook level customization, I prefer the createHook pattern like meta is better to pass one-shot options. But systemjs is packed as iife, so the createHook pattern is impossible, for global wise customization/options, user can override the hook and always patch the meta, but I don't know is this a good practice. |
I think meta should not used for extend assertions actions (e.g. extra loader, add more content type), just passing extra fetch option is acceptable, like override the request init System.register([], () => {...}, [{ request:{headers:{}} }]) or always use fetch as key System.register([], () => {...}, [{ fetch:{headers:{}} }]) or override fetch System.register([], () => {...}, [{ fetch:(u,o)=>fetch(u,{...o,headers:{}}) }]) Just adding headers will became confusing when there is a lot options for |
This is what concerns me - perhaps we should restrict the functionality for now rather? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The spec was changed to re‑use the with
keyword and renamed to “import
attributes”:
|
||
```js | ||
import { foo } from 'foo.js' assert { type: 'json' }; | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When using import assertion like | |
```js | |
import { foo } from 'foo.js' assert { type: 'json' }; | |
``` | |
When using import attributes like | |
```js | |
import { foo } from 'foo.js' with { type: 'json' }; | |
``` |
e.g. | ||
|
||
```js | ||
System.import('https://example.com/my-module.txt', {assert: {type: 'css'}}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
System.import('https://example.com/my-module.txt', {assert: {type: 'css'}}); | |
System.import('https://example.com/my-module.txt', {with: {type: 'css'}}); |
var assertType = ((meta || {}).assert || {}).type; | ||
return _shouldFetch(url, parent, meta) || moduleTypesRegEx.test(url) || !!loaders[assertType]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
var assertType = ((meta || {}).assert || {}).type; | |
return _shouldFetch(url, parent, meta) || moduleTypesRegEx.test(url) || !!loaders[assertType]; | |
var moduleType = ((meta || {}).with || {}).type; | |
return _shouldFetch(url, parent, meta) || moduleTypesRegEx.test(url) || !!loaders[moduleType]; |
test('should load a.txt as css module by assert', function () { | ||
return System.import('fixturesbase/css-modules/a.txt', {assert: {type: 'css'}}).then(function (m) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
test('should load a.txt as css module by assert', function () { | |
return System.import('fixturesbase/css-modules/a.txt', {assert: {type: 'css'}}).then(function (m) { | |
test('should load a.txt as css module by type attribute', function () { | |
return System.import('fixturesbase/css-modules/a.txt', {with: {type: 'css'}}).then(function (m) { |
test('should load a as css module by assert', function () { | ||
return System.import('fixturesbase/css-modules/a', {assert: {type: 'css'}}).then(function (m) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
test('should load a as css module by assert', function () { | |
return System.import('fixturesbase/css-modules/a', {assert: {type: 'css'}}).then(function (m) { | |
test('should load a as css module by type attribute', function () { | |
return System.import('fixturesbase/css-modules/a', {with: {type: 'css'}}).then(function (m) { |
No description provided.