Use require for optional module imports

Webpack issues a warning when trying to import() a module that is
not present, whereas it does not do so — or at least, not in a way
that blocks Next.js from building the app — with require(). Since
we're requiring a bundler anyway (since we're using npm package
names rather than import paths), we're not any worse off using a
non-standard module system for these.

For more info, see: webpack/webpack#7713

src/fetcher.ts

@@ -5,21 +5,22 @@ export const fetch: typeof window.fetch = (resource, init) => {
   // Implementation note: it's up to the client application to resolve these module names to the
   // respective npm packages. At least one commonly used tool (Webpack) is only able to do that if
   // the module names are literal strings.
-  const fetcherPromise = import(
-    // TypeScript cannot find the module - which is correct, since the consumer app should/can
-    // provide it:
-    // @ts-ignore
-    "@inrupt/solid-auth-fetcher"
-  )
-    .catch(() =>
-      import(
-        // TypeScript cannot find the module - which is correct, since the consumer app should/can
-        // provide it:
-        // @ts-ignore
-        "solid-auth-client"
-      )
-    )
-    .catch(() => import("cross-fetch"));
+  // Additionally, Webpack throws a warning in a way that halts compilation for at least Next.js
+  // when using native Javascript dynamic imports (`import()`), whereas `require()` just logs a
+  // warning. Since the use of package names instead of file names requires a bundles anyway, this
+  // should not have any practical consequences. For more background, see:
+  // https://github.com/webpack/webpack/issues/7713
+  let fetch;
 
-  return fetcherPromise.then(({ fetch }) => fetch(resource, init));
+  try {
+    fetch = require("@inrupt/solid-auth-fetcher").fetch;
+  } catch (e) {
+    try {
+      fetch = require("solid-auth-client").fetch;
+    } catch (e) {
+      fetch = require("cross-fetch");
+    }
+  }
+
+  return fetch(resource, init);
 };