Runtime URL import fails for ES modules with .js file extension

[smitev]

Verify canary release

• I verified that the issue exists in Next.js canary release

Provide environment information

Operating System:
  Platform: darwin
  Arch: x64
  Version: Darwin Kernel Version 20.6.0: Tue Feb 22 21:10:41 PST 2022; root:xnu-7195.141.26~1/RELEASE_X86_64
Binaries:
  Node: 16.14.0
  npm: 8.3.1
  Yarn: 1.22.18
  pnpm: N/A
Relevant packages:
  next: 12.1.6
  react: 18.1.0
  react-dom: 18.1.0

What browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

Describe the Bug

When I try to import a Framer component during runtime, I am getting this error:
TypeError: Failed to resolve module specifier "react/jsx-runtime". Relative references must start with either "/", "./", or "../".

I followed the guide from Framer Handshake and I can confirm that the Framer component is properly imported during build time.

I guess the problem is how the imported file is interpreted, in this case it's not interpreted as ES module.
According to handleExternals function in the "webpack.config.ts" it expects to have .mjs file extension:
https://github.com/vercel/next.js/blob/canary/packages/next/build/webpack-config.ts#L978

Expected Behavior

I expect the imported module to be interpreted as ES module based on the Content-Type header if contains a JavaScript MIME type such as text/javascript. Not based on the .mjs file extension.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules#aside_%E2%80%94_.mjs_versus_.js

To Reproduce

https://github.com/smitev/framer-handshake-runtime

import React, { useEffect, useState } from 'react';

export const FramerElement = () => {
  const [FramerComponent, setFramerComponent] = useState<any>(false);
  const url = 'https://framer.com/m/Tip-6qB7.js';

  useEffect(() => {
    import(/* webpackIgnore: true */ url)
      .then((mod) => {
        console.log(mod);
        setFramerComponent(mod.default);
      })
      .catch((err) => {
        console.log(err);
      });
  }, []);

  if (!FramerComponent) return <></>;

  return <FramerComponent />;
};

[balazsorban44]

I'll check with the team, in the meantime, I think you might want to check out next/dynamic to load components dynamically. The above could be rewritten as:

import dynamic from "next/dynamic"

const FramerComponent = dynamic(
  () => import("https://framer.com/m/Tip-6qB7.js"),
  { loading: () => <></> }
)

export default function FramerElement() {
  return <FramerComponent />
}

This seems to load correctly:

[smitev]

In your example with next/dynamic it works because you are providing the url directly and the import is executed during build time.

In my case I am providing the URL as variable and I expect to be imported during runtime.
And it's imported correctly, but the Framer component is not interpreted as ES module.

[balazsorban44]

So I had a deeper look at this and it doesn't seem to be a Next.js bug:

• Using runtime variables for URL imports prevents webpack from being able to optimize your code. (Furthermore, I just wonder if this has any security implications, like being able to inject any script if your data source is compromised).
• The source code you link to is only invoked at build-time, so it is irrelevant for your case, as well as the experimental.urlImports config, which does not have an effect here.
• I think this is the main point: This is not about ESM, the code fails because the script you try importing contains module specifiers, which browsers do not understand. You can check out import maps. See also: http://newspatrak.com/javascript/not-using-node-js-uncaught-typeerror-failed-to-resolve-module-specifier-three-relative-references-must-start-with-either-or/. I also checked with CRA, and it throws the same error, here is a reproduction: https://github.com/balazsorban44/36895-cra.
• We would recommend moving imports to the top-level, using next/dynamic in combination with ssr: false to prevent the code from being run in the server-side pass (eg. during build). This would also make use of experimental.urlImports. The Framer Handshake getting started example also uses top-level imports.

[github-actions]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.