support dynamic requires #2310

boneskull · 2024-06-07T20:06:52Z

Description

This PR adds support for dynamic requires via loadFromMap() and link() (in import-lite.js and link.js, respectively). importLocation()'s signature has also been modified for support.

To use this feature in either function, the following must be true:
1. The moduleTransforms option (in the appropriate options parameter) must not be present. These are asynchronous module transforms, which cannot be used by dynamic require.
2. The ReadPowers param must be a proper ReadPowers object (not just a ReadFn) and must contain both the new readSync, new isAbsolute, and filePathFromURL functions.
  anything, and we must delegate loading to the sync exit module handler.
3. The PackagePolicy of the CompartmentDescriptor must have a dynamic: true flag (see below)
If all of the above are true, then a compartment will be allowed to dynamically require something. If that thing still cannot be found in the compartment map, the sync "fallback" exit hook (see next item) will be executed.
The new importHookNow property can be provided via options, which is a synchronous exit module import hook.
ReadPowers.readSync() is necessary to read files synchronously which is necessary to load them synchronously.
ReadPowers.isAbsolute() is necessary to determine if the module specifier of a dynamic require is absolute. If it is, it could be just about anything, and must be loaded via the user-provided importNowHook (the sync exit module import hook).

Note: It's possible to do more work here to check if the module specifier belongs to any known compartment to avoid using the fallback--this would mean storing absolute paths somewhere when traversing node modules, then, at import time, determinng if the module specifier refers to a child path of some compartment's absolute path--but IMO this is a good first pass.
As an alternative to moduleTransforms, synchronous module transforms may be provided via the new syncModuleTransforms object. In a non-dynamic-require use-case, if present, syncModuleTransforms are combined with the moduleTransforms option; all sync module transforms are module transforms, but not all module transforms are sync module transforms.
All builtin parsers are now synchronous. User-defined parsers can be async, but this will disable dynamic require support.
@endo/evasive-transform now exports evadeCensorSync() in addition to evadeCensor(). This is possible because I've swapped the async-only source-map with source-map-js, which is a fork of the former before it went async-only. source-map-js claims comparable performance.
PackagePolicy now allows a dynamic flag. Piggybacking on options was considered, but the content of options is intended to be unknown to Endo. Thus, we needed a new property.

Security Considerations

Dynamically requiring an exit module (e.g., a Node.js builtin) requires a user-defined hook, which has the same security considerations as a user-defined exit module hook.

Swapping out a dependency (source-map-js for source-map) incurs risk.

Scaling Considerations

n/a

Documentation Considerations

Should be announced as a user-facing feature

Testing Considerations

I've added some fixtures and tested around the conditionals I've added, but am open to any suggestions for additional coverage.

Compatibility Considerations

This increases ecosystem compatibility considerably; use of dynamic require in the ecosystem is not rare.

For example, most packages which ship a native module will be using dynamic require, because the filepath of the build artifact is dependent upon the platform and architecture.

Upgrade Considerations

Dynamic imports cannot be used without providing a readSync() and isAbsolute() in the readPowers parameter. Both readSync() and isAbsolute() are now generated by makeReadPowersSloppy(), which means that any consumer using this method who previously expected a dynamic require to fail will now receive a different error (presumably due to the missing policy item).

To avoid this, I could create a separate function to provide a ReadPowers including readSync() and isAbsolute(), instead of changing makeReadPowersSloppy; please advise.

Otherwise, everything else should be backwards-compatible, as long as source-map-js does as it says on the tin.

Users of @endo/evasive-transform may note that native modules are neither downloaded/compiled (due to the switch from source-map to source-map-js).

boneskull · 2024-06-18T21:17:07Z

~~If anyone can point me in the direction of why the tests are failing, that'd be helpful; otherwise I'll just plug at it.~~ Plugged.

boneskull · 2024-06-18T23:26:16Z

packages/compartment-mapper/src/import-hook.js

+    compartmentDescriptor.modules = moduleDescriptors;
+
+    let { policy } = compartmentDescriptor;
+    policy = policy || Object.create(null);


this is for typescript

boneskull · 2024-06-18T23:28:25Z

packages/compartment-mapper/src/import-hook.js

+    if ('packages' in policy && typeof policy.packages === 'object') {
+      for (const [pkgName, policyItem] of entries(policy.packages)) {
+        if (
+          !(pkgName in compartmentDescriptor.modules) &&
+          pkgName in compartmentDescriptor.scopes &&
+          policyItem
+        ) {
+          compartmentDescriptor.modules[pkgName] =
+            compartmentDescriptor.scopes[pkgName];
+        }
+      }
+    }


I am unsure if this is correct, but it creates links between compartment descriptors based only on policy--where Endo would not have detected them otherwise.

Checking if dynamic: true is in policy at this point causes many tests to fail, because this ends up being a code path which many tests take. Why? Because the behavior is opt-out.

With regards to that, in addition to the policy, perhaps we should add a dynamic option to ImportLocationOptions or whathaveyou, so you can explicitly opt-in to using importNowHook. Right now, it's an opt-out based on the lack of a moduleTransforms (async module transforms) option and the shape of readPowers. It's not until later that we take the policy into account. Another way to put it: we're creating an importNowHook because a) we have the tools to do so, and b) something might dynamically require something else.

If we did that, I'd be able to delete some LoC, and we'd reduce the risk of introducing backwards-incompatible changes. Thoughts?

boneskull · 2024-06-18T23:28:48Z

packages/compartment-mapper/src/import-hook.js

+      // Collate candidate locations for the moduleSpecifier,
+      // to support Node.js conventions and similar.
+      const candidates = [moduleSpecifier];
+      for (const candidateSuffix of searchSuffixes) {
+        candidates.push(`${moduleSpecifier}${candidateSuffix}`);
+      }
+
+      for (const candidateSpecifier of candidates) {
+        const candidateModuleDescriptor = moduleDescriptors[candidateSpecifier];
+        if (candidateModuleDescriptor !== undefined) {
+          const { compartment: candidateCompartmentName = packageLocation } =
+            candidateModuleDescriptor;
+          const candidateCompartment = compartments[candidateCompartmentName];
+          if (candidateCompartment === undefined) {
+            throw Error(
+              `compartment missing for candidate ${candidateSpecifier} in ${candidateCompartmentName}`,
+            );
+          }
+          // modify compartmentMap to include this redirect
+          const candidateCompartmentDescriptor =
+            compartmentDescriptors[candidateCompartmentName];
+          if (candidateCompartmentDescriptor === undefined) {
+            throw Error(
+              `compartmentDescriptor missing for candidate ${candidateSpecifier} in ${candidateCompartmentName}`,
+            );
+          }
+          candidateCompartmentDescriptor.modules[moduleSpecifier] =
+            candidateModuleDescriptor;
+          // return a redirect
+          /** @type {RedirectStaticModuleInterface} */
+          const record = {
+            specifier: candidateSpecifier,
+            compartment: candidateCompartment,
+          };
+          return record;
+        }
+
+        // Using a specifier as a location.
+        // This is not always valid.
+        // But, for Node.js, when the specifier is relative and not a directory
+        // name, they are usable as URL's.
+        const moduleLocation = resolveLocation(
+          candidateSpecifier,
+          packageLocation,
+        );


This is a lot of duplication. I think this is worth trying to bounce on a trampoline.

Yeah. This is a good idea, but is also unfortunate because it will take me longer to land this.

boneskull · 2024-06-18T23:30:02Z

packages/compartment-mapper/src/import-hook.js

+        let moduleBytes;
+        try {
+          moduleBytes = readSync(moduleLocation);
+        } catch (err) {
+          if (err && err.code === 'ENOENT') {
+            // might be an exit module. use the fallback `exitModuleImportNowHook` to import it
+            // eslint-disable-next-line no-continue
+            continue;
+          }
+          throw err;
+        }


how do we know something is an exit module? maybe we should check the compartment descriptor, and only use the fallback if the thing doesn't exist there?

I have not arrived at a hard decision for this question. Falling through the bottom of the import hook should be enough, but might not be. An option we did not have when I first wrote this: we can identify “host modules” by the presence of a prefix: like node: or endo:. These would be guaranteed to escape the Node.js style mappings.

In the interest of keeping coupling to a specific specifier resolution strategy low, I am leaning heavily toward “pass through if nothing in the compartment map matches.”

boneskull · 2024-06-18T23:30:25Z

packages/compartment-mapper/src/import-hook.js

+        if (moduleBytes !== undefined) {
+          /** @type {string | undefined} */
+          let sourceMap;
+          // eslint-disable-next-line no-await-in-loop
+          const envelope = parse(
+            moduleBytes,
+            candidateSpecifier,
+            moduleLocation,
+            packageLocation,
+            {
+              compartmentDescriptor,
+              readPowers,
+              sourceMapHook:
+                sourceMapHook &&
+                (nextSourceMapObject => {
+                  sourceMap = JSON.stringify(nextSourceMapObject);
+                }),
+            },
+          );
+          const {
+            parser,
+            bytes: transformedBytes,
+            record: concreteRecord,
+          } = envelope;
+
+          // Facilitate a redirect if the returned record has a different
+          // module specifier than the requested one.
+          if (candidateSpecifier !== moduleSpecifier) {
+            moduleDescriptors[moduleSpecifier] = {
+              module: candidateSpecifier,
+              compartment: packageLocation,
+            };
+          }
+          /** @type {StaticModuleType} */
+          const record = {
+            record: concreteRecord,
+            specifier: candidateSpecifier,
+            importMeta: { url: moduleLocation },
+          };
+
+          let sha512;
+          if (computeSha512 !== undefined) {
+            sha512 = computeSha512(transformedBytes);
+
+            if (sourceMapHook !== undefined && sourceMap !== undefined) {
+              sourceMapHook(sourceMap, {
+                compartment: packageLocation,
+                module: candidateSpecifier,
+                location: moduleLocation,
+                sha512,
+              });
+            }
+          }
+
+          const packageRelativeLocation = moduleLocation.slice(
+            packageLocation.length,
+          );
+          packageSources[candidateSpecifier] = {
+            location: packageRelativeLocation,
+            sourceLocation: moduleLocation,
+            parser,
+            bytes: transformedBytes,
+            record: concreteRecord,
+            sha512,
+          };
+          for (const importSpecifier of getImportsFromRecord(record)) {
+            strictlyRequiredForCompartment(packageLocation).add(
+              resolve(importSpecifier, moduleSpecifier),
+            );
+          }
+
+          return record;
+        }
+      }


boneskull · 2024-06-18T23:31:18Z

packages/compartment-mapper/src/link.js

+ * @param {SyncModuleTransforms} moduleTransforms
+ * @returns {ParseFn}
+ */
+export const mapParsersSync = (


should probably just change mapParsers to handle both SyncModuleTransforms and ModuleTransforms...?

boneskull · 2024-06-18T23:33:56Z

packages/compartment-mapper/src/link.js

+        importNowHook = () => {
+          throw new Error(
+            `Dynamic require not allowed in compartment ${q(compartmentDescriptor.name)}`,
+          );
+        };


I'm not sure what else to do here.

Looking for the dynamic flag too early causes other tests to break, and would potentially need dynamic: true in the policy for attenuators (see here)

boneskull · 2024-06-18T23:35:13Z

packages/compartment-mapper/src/types.js

+/**
+ * @typedef FsPromisesApi
+ * @property {(filepath: string) => Promise<string>} realpath
+ * @property {WriteFn} writeFile
+ * @property {ReadFn} readFile
+ */
+
+/**
+ * @typedef FsAPI
+ * @property {FsPromisesApi} promises
+ * @property {ReadSyncFn} readFileSync
+ */
+
+/**
+ * @typedef UrlAPI
+ * @property {(location: string | URL) => string} fileURLToPath
+ * @property {(path: string) => URL} pathToFileURL
+ */
+
+/**
+ * @typedef CryptoAPI
+ * @property {typeof import('crypto').createHash} createHash
+ */


not strictly necessary, but I found it helpful. YMMV

kriskowal

Preliminary feedback.

kriskowal · 2024-06-19T00:18:11Z

packages/compartment-mapper/src/import-hook.js

 const freeze = Object.freeze;

+const entries = Object.entries;


Suggested change

const freeze = Object.freeze;

const entries = Object.entries;

const { entries, freeze } = Object;

kriskowal · 2024-06-19T00:19:31Z

packages/compartment-mapper/src/import-hook.js

+    let { policy } = compartmentDescriptor;
+    policy = policy || Object.create(null);


Does TypeScript not like this pattern:?

Suggested change

let { policy } = compartmentDescriptor;

policy = policy || Object.create(null);

const { policy = create(null) } = compartmentDescriptor;

Ah, thought if we’re coming off of JSON and using the in operator, it might be better to ensure that the policy has a null proto, something like:

const policy = { __proto__: null, ...(compartment.descriptor.policy || {}) };

Or:

const policy = assign(create(null), compartment.descriptor.policy || {});

To answer your first question: no; it is inferred to be {} instead of CompartmentDescriptor.

I'll take a few putts at it, but if I bogey I'm just going to leave it as-is.

kriskowal · 2024-06-19T00:24:39Z

packages/compartment-mapper/src/import-hook.js

+    // associates modules with compartment descriptors based on policy
+    // which wouldn't otherwise be there
+    if ('packages' in policy && typeof policy.packages === 'object') {
+      for (const [pkgName, policyItem] of entries(policy.packages)) {


Style nit: I’ve generally elsewhere avoided abbreviating package to pkg. policyItem should probably be something like compartmentPolicy or packakgePolicy to increase the specificity of “item” to the scope it covers.

kriskowal · 2024-06-19T00:28:33Z

packages/compartment-mapper/src/import-hook.js

+        try {
+          moduleBytes = readSync(moduleLocation);
+        } catch (err) {
+          if (err && err.code === 'ENOENT') {


This is coupled too closely to Node.js. The coupling should only exist in the Node.js powers. We have an analogous maybeRead that returns undefined if the file is not found. We will need a maybeReadSync power.

kriskowal · 2024-06-19T00:30:22Z

packages/compartment-mapper/src/import-hook.js

+      // Collate candidate locations for the moduleSpecifier,
+      // to support Node.js conventions and similar.
+      const candidates = [moduleSpecifier];
+      for (const candidateSuffix of searchSuffixes) {
+        candidates.push(`${moduleSpecifier}${candidateSuffix}`);
+      }
+
+      for (const candidateSpecifier of candidates) {
+        const candidateModuleDescriptor = moduleDescriptors[candidateSpecifier];
+        if (candidateModuleDescriptor !== undefined) {
+          const { compartment: candidateCompartmentName = packageLocation } =
+            candidateModuleDescriptor;
+          const candidateCompartment = compartments[candidateCompartmentName];
+          if (candidateCompartment === undefined) {
+            throw Error(
+              `compartment missing for candidate ${candidateSpecifier} in ${candidateCompartmentName}`,
+            );
+          }
+          // modify compartmentMap to include this redirect
+          const candidateCompartmentDescriptor =
+            compartmentDescriptors[candidateCompartmentName];
+          if (candidateCompartmentDescriptor === undefined) {
+            throw Error(
+              `compartmentDescriptor missing for candidate ${candidateSpecifier} in ${candidateCompartmentName}`,
+            );
+          }
+          candidateCompartmentDescriptor.modules[moduleSpecifier] =
+            candidateModuleDescriptor;
+          // return a redirect
+          /** @type {RedirectStaticModuleInterface} */
+          const record = {
+            specifier: candidateSpecifier,
+            compartment: candidateCompartment,
+          };
+          return record;
+        }
+
+        // Using a specifier as a location.
+        // This is not always valid.
+        // But, for Node.js, when the specifier is relative and not a directory
+        // name, they are usable as URL's.
+        const moduleLocation = resolveLocation(
+          candidateSpecifier,
+          packageLocation,
+        );


This is a lot of duplication. I think this is worth trying to bounce on a trampoline.

kriskowal · 2024-06-19T00:35:15Z

packages/compartment-mapper/src/import-lite.js

@@ -55,6 +87,44 @@ export const loadFromMap = async (readPowers, compartmentMap, options = {}) => {
    assign(create(null), languageForExtensionOption),
  );

+  /**
+   * Object containing options and read powers which fulfills all requirements


Suggested change

* Object containing options and read powers which fulfills all requirements

* Object containing options and read powers that fulfills all requirements

kriskowal · 2024-06-19T00:35:33Z

packages/compartment-mapper/src/import-lite.js

@@ -55,6 +87,44 @@ export const loadFromMap = async (readPowers, compartmentMap, options = {}) => {
    assign(create(null), languageForExtensionOption),
  );

+  /**
+   * Object containing options and read powers which fulfills all requirements
+   * for creation of a {@link ImportNowHookMaker}, thus enabling dynamic import


Suggested change

* for creation of a {@link ImportNowHookMaker}, thus enabling dynamic import

* for creation of a {@link ImportNowHookMaker}, thus enabling dynamic import.

kriskowal · 2024-06-19T00:35:58Z

packages/compartment-mapper/src/import-lite.js

+
+  /**
+   * Object containing options and read powers which is incompatible with
+   * creation of a {@link ImportNowHookMaker}, thus disabling dynamic import


Suggested change

* creation of a {@link ImportNowHookMaker}, thus disabling dynamic import

* creation of an {@link ImportNowHookMaker}, thus disabling dynamic import.

kriskowal · 2024-06-19T00:42:09Z

packages/evasive-transform/src/location-unmapper.js

@@ -4,7 +4,7 @@
 * @module
 */

-import { SourceMapConsumer } from 'source-map';
+import { SourceMapConsumer } from 'source-map-js';


I’d be happy to review this change to evasive-transform separately to make this one smaller and land it faster.

kriskowal · 2024-06-19T00:50:19Z

packages/compartment-mapper/src/import-lite.js

+    if (behavior.type === 'SYNC') {
+      const { importNowHook: exitModuleImportNowHook, syncModuleTransforms } =
+        behavior.options;
+      makeImportNowHook = makeImportNowHookMaker(
+        /** @type {SyncReadPowers} */ (readPowers),
+        entryCompartmentName,
+        {
+          compartmentDescriptors: compartmentMap.compartments,
+          searchSuffixes,
+          exitModuleImportNowHook,
+        },
+      );
+      ({ compartment, pendingJobsPromise } = link(compartmentMap, {
+        makeImportHook,
+        makeImportNowHook,
+        parserForLanguage,
+        languageForExtension,
+        globals,
+        transforms,
+        syncModuleTransforms,
+        __shimTransforms__,
+        Compartment,
+      }));
+    } else {
+      // sync module transforms are allowed, because they are "compatible"
+      // with async module transforms (not vice-versa)
+      const moduleTransforms = /** @type {ModuleTransforms} */ ({
+        ...behavior.options.syncModuleTransforms,
+        ...behavior.options.moduleTransforms,
+      });
+      ({ compartment, pendingJobsPromise } = link(compartmentMap, {
+        makeImportHook,
+        parserForLanguage,
+        languageForExtension,
+        globals,
+        transforms,
+        moduleTransforms,
+        __shimTransforms__,
+        Compartment,
+      }));
+    }


I need to think more about what it would take to make this work with a single call to link, deferring the problem of differentiating these cases to the link implementation. That might be by passing a sync: true option into link.

Maybe this would give us more options: SES currently accepts both importHook and importNowHook but only consults one or the other. We could change Compartment#import to consult importNowHook before importHook, proceeding to the later only if the former returns undefined. Maybe that would let us get more bang from importNowHook. Or perhaps we just need that trampoline.

boneskull · 2024-06-24T20:00:44Z

Going to extract the changes to @endo/evasive-transform into a separate PR.

boneskull · 2024-06-24T20:36:09Z

Ref: #2332

cc @kriskowal

boneskull · 2024-06-24T20:36:55Z

Once #2332 is merged, I can rebase this onto master, which should eliminate the commit from this PR's history. So let's sit on it until then.

This change: 1. Creates a minimal interface for the `fs`, `url`, and `crypto` objects as passed into `makeReadPowers()`. This makes it easier to duck-type the objects. 2. Fixes the invalid type of `MaybeReadPowers`; properties (defined thru `@property`) are ignored in a `@typedef` of that `@typedef` does not extend `object`/`Object`. 3. Added necessary type assertion in `powers.js` 4. Adds return type to `makeReadPowersSloppy()` # Conflicts: # packages/compartment-mapper/src/types.js

This change replaces [source-map](https://npm.im/source-map) with [source-map-js](https://npm.im/source-map-js), which is a fork of the former. Crucially, `source-map-js` is a synchronous, pure-JS implementation. A consequence of this is that `makeLocationUnmapper` is now synchronous. It is internal, however. `evadeCensor` now just wraps `evadeCensorSync` in a `Promise`. Tests have been changed to use `evadeCensorSync` directly. In the `makeLocationUnmapper` implementation, an assertion for the truthiness of `ast.loc` has been moved _before_ instantiation of `SourceMapConsumer`, where it maybe should have been in the first place.

Is this a breaking change? I don't know. This doesn't mean that parsers _cannot_ be async--just rather that the ones we have are not.

This adds a new prop to `ReadPowers`: `isAbsolute()`. This function is used to load such a module specifier as an exit module in `importNowHook`, since it could be pointing to anything.

…quire support - improve error messages - better tests to support the `node-gyp-build` use-case

boneskull mentioned this pull request Jun 7, 2024

feat: unnamed lavamoat-node replacement LavaMoat/LavaMoat#772

Draft

1 task

boneskull force-pushed the boneskull/dynamic branch from 2135d35 to 8df8629 Compare June 12, 2024 23:03

BellaBijl approved these changes Jun 18, 2024

View reviewed changes

boneskull self-assigned this Jun 18, 2024

boneskull marked this pull request as ready for review June 18, 2024 20:57

boneskull requested review from kriskowal and naugtur June 18, 2024 20:57

boneskull force-pushed the boneskull/dynamic branch from 44ea8db to 54ee067 Compare June 18, 2024 21:02

boneskull commented Jun 18, 2024

View reviewed changes

kriskowal reviewed Jun 19, 2024

View reviewed changes

boneskull force-pushed the boneskull/dynamic branch from 506d990 to 45c147e Compare June 19, 2024 20:53

boneskull added 8 commits June 24, 2024 13:48

fix(compartment-mapper): all parsers are now synchronous

64c4566

Is this a breaking change? I don't know. This doesn't mean that parsers _cannot_ be async--just rather that the ones we have are not.

chore(compartment-mapper): simplify some types in policy.js

f763fe0

feat(compartment-mapper): support dynamic imports

7e0d1ea

fix(compartment-mapper): allow dynamic imports of exit modules

417f98e

chore(compartment-mapper): add tests for dynamic require

87cfd4b

chore: rename things, cleanup & and more tests

23461d1

boneskull added 5 commits June 24, 2024 13:48

chore: add policy requirement; fix test failures

cbc5382

chore(compartment-mapper): normalize TS imports in policy.js

cc01cb7

chore(compartment-mapper): strongly type a function for lulz

3edacce

fix(compartment-mapper): require isAbsolute for dynamic imports

3f597ad

This adds a new prop to `ReadPowers`: `isAbsolute()`. This function is used to load such a module specifier as an exit module in `importNowHook`, since it could be pointing to anything.

fix(compartment-mapper): importNowHook is now required for dynamic re…

0e5fb1b

…quire support - improve error messages - better tests to support the `node-gyp-build` use-case

boneskull force-pushed the boneskull/dynamic branch from 3861722 to 0e5fb1b Compare June 24, 2024 23:10

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

support dynamic requires #2310

support dynamic requires #2310

boneskull commented Jun 7, 2024 •

edited

Loading

boneskull commented Jun 18, 2024 •

edited

Loading

boneskull Jun 18, 2024

boneskull Jun 18, 2024 •

edited

Loading

boneskull Jun 18, 2024

kriskowal Jun 19, 2024

boneskull Jun 24, 2024

boneskull Jun 18, 2024

kriskowal Jun 19, 2024

boneskull Jun 18, 2024

boneskull Jun 18, 2024

boneskull Jun 18, 2024

boneskull Jun 18, 2024

kriskowal left a comment

kriskowal Jun 19, 2024

kriskowal Jun 19, 2024

kriskowal Jun 19, 2024

boneskull Jun 24, 2024

kriskowal Jun 19, 2024

kriskowal Jun 19, 2024

kriskowal Jun 19, 2024

kriskowal Jun 19, 2024

kriskowal Jun 19, 2024

kriskowal Jun 19, 2024

kriskowal Jun 19, 2024

kriskowal Jun 19, 2024

boneskull commented Jun 24, 2024

boneskull commented Jun 24, 2024

boneskull commented Jun 24, 2024

		const freeze = Object.freeze;

		const entries = Object.entries;

		let { policy } = compartmentDescriptor;
		policy = policy \|\| Object.create(null);

	let { policy } = compartmentDescriptor;
	policy = policy \|\| Object.create(null);
	const { policy = create(null) } = compartmentDescriptor;

	* Object containing options and read powers which fulfills all requirements
	* Object containing options and read powers that fulfills all requirements

	* for creation of a {@link ImportNowHookMaker}, thus enabling dynamic import
	* for creation of a {@link ImportNowHookMaker}, thus enabling dynamic import.

	* creation of a {@link ImportNowHookMaker}, thus disabling dynamic import
	* creation of an {@link ImportNowHookMaker}, thus disabling dynamic import.

support dynamic requires #2310

Are you sure you want to change the base?

support dynamic requires #2310

Conversation

boneskull commented Jun 7, 2024 • edited Loading

Description

Security Considerations

Scaling Considerations

Documentation Considerations

Testing Considerations

Compatibility Considerations

Upgrade Considerations

boneskull commented Jun 18, 2024 • edited Loading

Choose a reason for hiding this comment

boneskull Jun 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kriskowal left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

boneskull commented Jun 24, 2024

boneskull commented Jun 24, 2024

boneskull commented Jun 24, 2024

boneskull commented Jun 7, 2024 •

edited

Loading

boneskull commented Jun 18, 2024 •

edited

Loading

boneskull Jun 18, 2024 •

edited

Loading