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

Forward compatibility of ignoring unknown keys in the import(…) options bag #121

Open
fstirlitz opened this issue Apr 7, 2022 · 1 comment

Comments

@fstirlitz
Copy link

This proposal adds a second… operand(?) to the import(...) expression, an options bag. As I understand it, it is meant to be an extensible mechanism that other language enhancements that modify the importing process may take advantage of.

As currently specified, EvaluateImportCall is defined to ignore the presence of unrecognized keys in the options bag. As far as this proposal is concerned, this is fine, because assertions are meant to be applied opportunistically, and if they pass, they don’t change the semantics of importing; however, there are already proposals in the works building upon this one that do. For example, https://github.com/tc39/proposal-import-reflection may import the module as an entirely different object.

My question is, how is user code to know whether an import option was actually taken into account by the host? How should it prevent a situation where an import call ostensibly returns success, but with the wrong semantics? (e.g. importing a JSON file as if it were an ECMAScript module)

@fstirlitz
Copy link
Author

I suppose one may use hardenedImport instead:

const hardenedImport = async (specifier, options = {}) => {
	const keysRead = Object.create(null);

	const ns = await import(specifier, new Proxy(options, {
		get(target, key, proxy) {
			keysRead[key] = true;
			return Reflect.get(target, key);
		}
	}));

	for (const key of Object.keys(options)) {
		if (!keysRead[key]) {
			throw new TypeError(`improper import: option ${String(key)} ignored`);
		}
	}

	return ns;
}

But this is not a very convenient option, and it is still dangerous in that the lack of support is only detected after the import is complete, which may have had already triggered unwanted side effects. Though at least this trick would allow probing for features in controlled conditions:

const isImportOptionSupported = option => {
	let supported = false;
	import(
		// or `module {}`, per <https://github.com/tc39/proposal-js-module-blocks>
		'data:text/javascript,',
		{ get [option]() { supported = true; } }
	).catch(() => {});
	return supported;
};

const getSupportedImportOptions = () => {
	const features = Object.create(null);
	import('data:text/javascript,', new Proxy({}, {
		get(target, key, proxy) { features[key] = true; }
	})).catch(() => {});
	return features;
};

Though that still may fail if any conditionally-checked option keys are added.

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

1 participant