vscode-apollo 2.3.3 → 2.3.5

package/.github/workflows/E2E.yml

@@ -8,8 +8,11 @@ jobs:
   test:
     name: Run E2E tests
     runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        version: ["1.90.0", "stable", "insiders"]
     steps:
-      - run: sudo apt update && sudo apt install -y libasound2 libgbm1 libgtk-3-0 libnss3 xvfb expect
+      - run: sudo apt update && sudo apt install -y libasound2t64 libgbm1 libgtk-3-0 libnss3 xvfb expect
       - uses: actions/checkout@v4
       - uses: actions/setup-node@v4
         with:
@@ -25,3 +28,5 @@ jobs:
           expect eof
           EOF
       - run: xvfb-run -a npm run test:extension
+        env:
+          VSCODE_VERSION: "${{ matrix.version }}"

package/CHANGELOG.md

@@ -1,5 +1,17 @@
 # CHANGELOG
 
+## 2.3.5
+
+### Patch Changes
+
+- [#226](https://github.com/apollographql/vscode-graphql/pull/226) [`57c51c81`](https://github.com/apollographql/vscode-graphql/commit/57c51c81ec56d68c2226f0b169ed849fcbdaad55) Thanks [@yesmeck](https://github.com/yesmeck)! - Fixes config files being unable to load in old VSCode versions
+
+## 2.3.4
+
+### Patch Changes
+
+- [#224](https://github.com/apollographql/vscode-graphql/pull/224) [`b7d300f7`](https://github.com/apollographql/vscode-graphql/commit/b7d300f7d44138ef656bf5e5359dc284d41b78e2) Thanks [@phryneas](https://github.com/phryneas)! - Fix a situation where config files using `require` would not be imported as CommonJS.
+
 ## 2.3.3
 
 ### Patch Changes

package/README.md

@@ -9,7 +9,7 @@
 
 </div>
 
-GraphQL has the potential to create incredible developer experiences, thanks to its strongly typed schema and query language. The Apollo platform brings these possibilities to life by enhancing your editor with rich metadata from your graph API.
+Thanks to its strongly typed schema and query language, GraphQL has the potential to create incredible developer experiences. The Apollo platform brings these possibilities to life by enhancing your editor with rich metadata from your graph API.
 
 ![demo](https://raw.githubusercontent.com/apollographql/vscode-graphql/main/images/marketplace/jump-to-def.gif)
 
@@ -17,8 +17,9 @@ The Apollo GraphQL extension for VS Code brings an all-in-one tooling experience
 
 - Add [syntax highlighting](#syntax-highlighting) for GraphQL files and gql templates inside JavaScript files
 - Get instant feedback and [intelligent autocomplete](#intelligent-autocomplete) for fields, arguments, types, and variables as you write queries
-- Manage client side schema alongside remote schema
+- Manage client-side schema alongside remote schema
 - See [performance information](#performance-insights) inline with your query definitions
+- Extra features to help you with [supergraph editing](#supergraph-editing)
 - Validate field and argument usage in operations
 - [Navigate projects more easily](#navigating-projects) with jump-to and peek-at definitions
 - Manage [client-only](#client-only-schemas) schemas
@@ -26,24 +27,22 @@ The Apollo GraphQL extension for VS Code brings an all-in-one tooling experience
 
 <h2 id="getting-started">Getting started</h2>
 
-For the VS Code plugin to know how to find the schema, it needs to be linked to either a published schema or a local one.
-
-First, create an `apollo.config.json` file at the root of the project.
+The VS Code plugin must be linked to a published or local schema. To do so, create an `apollo.config.json` file at the root of the project.
 Alternatively, you can create a `yaml`, `cjs`, `mjs`, or `ts` file with the same configuration.
 
 For the contents of this configuration file, select one of these options:
 
-<h3>Configure extension for schemas published to Apollo GraphOS</h3>
+<h3>Configure extension for client development with schemas published to Apollo GraphOS</h3>
 <details>
 <summary>
 <i>Expand for instructions.</i>
 </summary>
 
-To get all the benefits of the VS Code experience, it's best to link the schema that is being developed against before installing the extension. The best way to do that is by [publishing a schema](https://www.apollographql.com/docs/graphos/delivery/publishing-schemas/) to the Apollo schema registry.
+To get all the benefits of the VS Code experience, it's best to link the schema being developed before installing the extension. The best way to do that is by [publishing a schema](https://www.apollographql.com/docs/graphos/delivery/publishing-schemas/) to the [GraphOS schema registry](https://www.apollographql.com/docs/graphos#core-features).
 
 After that's done, edit the `apollo.config.json` file to look like this:
 
-```json
+```jsonc
 {
   "client": {
     "service": "graphos-graph-name"
@@ -55,31 +54,68 @@ The `service` name is the name of the graph you've created in [GraphOS Studio](h
 
 See [additional configuration options](#additional-apollo-config-options).
 
-To authenticate with GraphOS Studio to pull down your schema, create a `.env` file in the same directory as the `apollo.config.json` file. This should be an untracked file (that is, don't commit it to Git).
+To authenticate with GraphOS Studio to pull down your schema, create an `.env` file in the same directory as the `apollo.config.json` file. The `.env` file should be untracked—that is, don't commit it to Git.
 
-Then go to your [User Settings page](https://studio.apollographql.com/user-settings/api-keys?referrer=docs-content) in GraphOS Studio to create a new Personal API key.
+Then, go to your [User Settings page](https://studio.apollographql.com/user-settings/api-keys?referrer=docs-content) in GraphOS Studio to create a new personal API key.
 
-> It is best practice to create a new API key for each member of the team and name the key so its easy to find and revoke if needed. This will be easier to manage in the future.
+> It's best practice to create a new API key for each team member. API keys should also be named so they're easy to find and revoke if needed.
 
-After the key is found, add the following line to the `.env` file:
+After you've created your API key, add the following line to the `.env` file:
 
 ```bash showLineNumbers=false
 APOLLO_KEY=<enter copied key here>
 ```
 
-After this is done, VS Code can be reloaded and the Apollo integration will connect to GraphOS Studio to provide autocomplete, validation, and more.
+Afterward, reload VS Code. The Apollo integration will connect to GraphOS Studio to provide autocomplete, validation, and more.
 
 </details>
 
-<h3 id="local-schemas">Configure extension to use introspection from a locally running service</h3>
+<h3>Configure extension for supergraph schema development</h3>
 <details>
 <summary>
 <i>Expand for instructions.</i>
 </summary>
 
-Sometimes it may make sense to link the editor to a locally running version of a schema to try out new designs that are in active development. To do this, the `apollo.config.json` file can be linked to a local service definition:
+The extension can integrate with the [Rover CLI](https://www.apollographql.com/docs/rover/) to help you design supergraph schemas with additional support for Apollo Federation.
+
+Ensure you've [installed](https://www.apollographql.com/docs/rover/getting-started) and [configured](https://www.apollographql.com/docs/rover/configuring) the [latest Rover release](https://github.com/apollographql/rover/releases).
+
+Next edit your `apollo.config.json` to look like this:
+
+```jsonc
+{
+  "rover": {
+    // optional, if your rover binary is in PATH it will automatically be detected
+    "bin": "/path/to/rover",
+    // optional, defaults to `supergraph.yaml` in the folder of the configuration file
+    "supergraphConfig": "/path/to/supergraph.yaml",
+    // optional, defaults to the Rover default profile
+    "profile": ""
+  }
+}
+```
+
+Since all these options are optional, you can specify only the `rover` key to indicate you're using Rover for schema development rather than client development:
 
-```json
+```jsonc
+{
+  "rover": {}
+}
+```
+
+Afterward, reload VS Code. The Apollo extension will start using Rover to help you build your supergraph.
+
+</details>
+
+<h3 id="local-schemas">Configure extension for client development with introspection from a locally running service</h3>
+<details>
+<summary>
+<i>Expand for instructions.</i>
+</summary>
+
+To experiment with designs under active development, you can link the editor to a locally running version of a schema. Link the `apollo.config.json` file to a local service definition like so:
+
+```jsonc
 {
   "client": {
     "service": {
@@ -90,11 +126,11 @@ Sometimes it may make sense to link the editor to a locally running version of a
 }
 ```
 
-Linking to the local schema won't provide all features, such as switching graph variants and performance metrics.
+Linking to local schemas won't provide all extension features, such as switching graph variants and performance metrics.
 
 </details>
 
-<h3 id="local-schema-files">Configure extension for local schema files</h3>
+<h3 id="local-schema-files">Configure extension for client development with local schema files</h3>
 <details>
 <summary>
 <i>Expand for instructions.</i>
@@ -104,7 +140,7 @@ You might not always have a running server to link to, so the extension also sup
 This is useful for working on a schema in isolation or for testing out new features.
 To link to a local schema file, add the following to the `apollo.config.json` file:
 
-```json
+```jsonc
 {
   "client": {
     "service": {
@@ -117,13 +153,17 @@ To link to a local schema file, add the following to the `apollo.config.json` fi
 
 </details>
 
-<h3 id="client-only-schemas">Adding Client-only schemas</h3>
+<h3 id="client-only-schemas">Bonus: Adding client-only schemas</h3>
+<details>
+<summary>
+<i>Expand for instructions.</i>
+</summary>
 
-One of the best features of the VS Code extension is the automatic merging of remote schemas and local ones when using integrated state management with Apollo Client. This happens automatically whenever schema definitions are found within a client project. By default, the VS Code extension will look for all JavaScript, TypeScript and GraphQL files under `./src` to find both the operations and schema definitions for building a complete schema for the application.
+One of the best features of the VS Code extension is the automatic merging of remote and local schemas when using integrated state management with Apollo Client. This happens automatically whenever schema definitions are found within a client project. By default, the VS Code extension will look for all JavaScript, TypeScript, and GraphQL files under `./src` to find both the operations and schema definitions for building a complete schema for the application.
 
-Client side schema definitions can be spread throughout the client app project and will be merged together to create one single schema. The default behavior can be controlled by adding specifications to the `apollo.config.json`:
+Client-side schema definitions can be spread throughout the client app project and will be merged to create one single schema. You can set the default behavior by adding specifications to the `apollo.config.json`:
 
-```json
+```jsonc
 {
   "client": {
     // "service": <your service configuration>,
@@ -135,17 +175,19 @@ Client side schema definitions can be spread throughout the client app project a
 }
 ```
 
+</details>
+
 <h3 id="get-the-extension">Get the extension</h3>
 
 Once you have a config set up and a schema published, [install the Apollo GraphQL extension](https://marketplace.visualstudio.com/items?itemName=apollographql.vscode-apollo), then try opening a file containing a GraphQL operation.
 
-When a file open, clicking the status bar icon will open the output window and print stats about the project associated with that file. This is helpful when confirming the project is setup properly.
+After opening a file, click the status bar icon to open the output window and see stats about the project associated with that file. This is helpful for confirming that the project is set up properly.
 
 <img src="https://raw.githubusercontent.com/apollographql/vscode-graphql/main/images/marketplace/stats.gif"  alt="Clicking the status bar icon to open the output pane">
 
 <h2 id="features">Features</h2>
 
-Apollo for VS Code brings many helpful features for working on a GraphQL project.
+Apollo for VS Code offers a range of useful features for working on GraphQL projects.
 
 <h3 id="intelligent-autocomplete">Intelligent autocomplete</h3>
 
@@ -155,24 +197,24 @@ Once configured, VS Code has full knowledge of the schema clients are running op
 
 <h3 id="errors-and-warnings">Inline errors and warnings</h3>
 
-VS Code can use local or published schemas to validate operations before running them. **Syntax errors**, **invalid fields or arguments**, and even **deprecated fields** instantly appear as errors or warnings right in your editor, ensuring all developers are working with the most up-to-date production schemas.
+VS Code can use local or published schemas to validate operations before running them. **Syntax errors**, **invalid fields or arguments**, and even **deprecated fields** instantly appear as errors or warnings in your editor, ensuring your entire team is working with the most up-to-date production schemas.
 
 <img src="https://raw.githubusercontent.com/apollographql/vscode-graphql/main/images/marketplace/warnings-and-errors.gif"  alt="tooltip showing a field deprecation warning and error">
 
 <h3 id="field-type-info">Inline field type information</h3>
 
-Because of GraphQL's strongly-typed schema, VS Code not only know about which fields and arguments are valid, but also what types are expected. Hover over any type in a valid GraphQL operation to see what type that field returns and whether or not it can be null.
+Because of GraphQL's strongly typed schema, VS Code knows not only which fields and arguments are valid, but also what types are expected. Hover over any type in a valid GraphQL operation to see what type that field returns and whether or not it can be null.
 
 <img src="https://raw.githubusercontent.com/apollographql/vscode-graphql/main/images/marketplace/type-info.png" style="max-width:800px;" alt="a tooltip showing a Boolean type for a field">
 
 <h3 id="performance-insights">Performance insights</h3>
 
-GraphQL's flexibility can make it difficult to predict the cost of an operation. Without insight into how expensive an operation is, developers can accidentally write queries that place strain on their graph API's underlying backends. Thanks to the Apollo platform's integration with VS Code and our trace warehouse, teams can avoid these performance issues altogether by instantly seeing the cost of a query right in their editor.
+GraphQL's flexibility can make it difficult to predict the cost of an operation. Without insight into how expensive an operation is, developers can accidentally write queries that place strain on their graph API's underlying backends. Thanks to the Apollo platform's integration with VS Code and our trace warehouse, teams can avoid these performance issues by instantly seeing the cost of a query in their editor.
 
-The VS Code extension will show inline performance diagnostics when connected to a service with reported metrics in GraphOS Studio. As operations are typed, any fields that take longer than 1 ms to respond will be annotated to the right of the field inline! This gives team members a picture of how long the operation will take as more and more fields are added to operations or fragments.
+The VS Code extension will show inline performance diagnostics when connected to a service with reported metrics in GraphOS Studio. As operations are typed, any fields that take longer than 1 ms to respond will be annotated to the right of the field inline. This shows team members how long the operation will take as more and more fields are added to operations or fragments.
 
 <img
-  src="https://raw.githubusercontent.com/apollographql/vscode-graphql/80a6ca4ae59173b8cef25020345e4ebe202eec41/images/marketplace/perf-annotation.png"
+  src="https://raw.githubusercontent.com/apollographql/vscode-graphql/main/images/marketplace/perf-annotation.png"
   width="80%"
   style="margin: 5%"
   alt="Performance annotation next to a field"
@@ -180,11 +222,20 @@ The VS Code extension will show inline performance diagnostics when connected to
 
 <h3 id="syntax-highlighting">Syntax highlighting</h3>
 
-Apollo's editor extension provides syntax highlighting for all things GraphQL, including schema definitions in `.graphql` files, complex queries in TypeScript, and even client-only schema extensions. Syntax highlighting for GraphQL works out-of-the-box for `.graphql`, `.gql`, `.js` and `.ts` file types.
+Apollo's editor extension provides syntax highlighting for all things GraphQL, including schema definitions in `.graphql` files, complex queries in TypeScript, and even client-only schema extensions. Syntax highlighting for GraphQL works out-of-the-box in GraphQL, JavaScript, TypeScript, Python, Lua, Ruby, Dart, Elixir, and ReasonML files.
+
+<h3 id="supergraph-editing">supergraph editing</h3>
+
+The extension provides features for supergraph editing, such as support for Federation directives, subgraph-spanning go-to-definition, and reporting composition errors directly to the **Problems** panel.
+
+<img
+  src="https://raw.githubusercontent.com/apollographql/vscode-graphql/main/images/marketplace/federation-directive-hover.png"
+  alt="Hover on Federation directive"
+/>
 
 <h3 id="navigating-projects">Navigating projects</h3>
 
-Navigating large codebases can be difficult, but the Apollo GraphQL extension makes this easier. Right-clicking on any field in operations or schemas gives you the ability to jump to (or peek at) definitions, as well as find any other references to that field in your project.
+Navigating large codebases can be difficult, but the Apollo GraphQL extension makes this easier. Right-clicking on any field in operations or schemas allows you to jump to (or peek at) definitions and find any other references to that field in your project.
 
 <img src="https://raw.githubusercontent.com/apollographql/vscode-graphql/main/images/marketplace/jump-to-def.gif"  alt="Using jump to definition on a fragment">
 
@@ -194,11 +245,11 @@ Apollo supports publishing multiple versions ([variants](https://www.apollograph
 
 <h2 id="troubleshooting">Troubleshooting</h2>
 
-The most common errors are configuration errors, like a missing `.env` file or incorrect service information in the `apollo.config.js` file. Please see [the Apollo config docs](https://www.apollographql.com/docs/devtools/apollo-config/) for more configuration guidance.
+The most common errors are configuration errors, like a missing `.env` file or incorrect service information in the `apollo.config.json` file. Please see [the Apollo config docs](https://www.apollographql.com/docs/devtools/apollo-config/) for more configuration guidance.
 
-Other errors may be caused from an old version of a published schema. To reload a schema, open the Command Palette (`cmd + shift + p` on mac), search "Apollo" and choose the "Apollo: Reload Schema" option.
+An old version of a published schema may cause other errors. To reload a schema, open the **Command Palette** (`cmd + shift + p` on Mac), search for "Apollo." Choose the **Apollo: Reload Schema** option.
 
-Sometimes errors will show up as a notification at the bottom of your editor. Other, less critical, messages may be shown in the output pane of the editor. To open the output pane and get diagnostic information about the extension and the current service loaded (if working with a client project), just click the "Apollo GraphQL" icon in the status bar at the bottom.
+Sometimes, errors will appear as a notification at the bottom of your editor. Other, less critical, messages may be shown in the output pane of the editor. To open the output pane and get diagnostic information about the extension and the current service loaded (if working with a client project), click the Apollo GraphQL icon in the status bar at the bottom.
 
 <img src="https://raw.githubusercontent.com/apollographql/vscode-graphql/main/images/marketplace/stats.gif"  alt="Clicking the status bar icon to open the output pane">
 
@@ -214,7 +265,7 @@ _Optional_ - custom tagged template literal.
 
 When using GraphQL with JavaScript or TypeScript projects, it is common to use the `gql` tagged template literal to write out operations. Apollo tools look through your files for the `gql` tag to extract your queries, so if you use a different template literal, you can configure it like so:
 
-```json
+```jsonc
 {
   "client": {
     "tagName": "graphql",

package/package.json

@@ -2,7 +2,7 @@
   "name": "vscode-apollo",
   "displayName": "Apollo GraphQL",
   "description": "Rich editor support for GraphQL client and server development that seamlessly integrates with the Apollo platform",
-  "version": "2.3.3",
+  "version": "2.3.5",
   "referenceID": "87197759-7617-40d0-b32e-46d378e907c7",
   "author": "Apollo GraphQL <opensource@apollographql.com>",
   "license": "MIT",

package/src/__e2e__/runTests.js

@@ -28,6 +28,7 @@ async function main() {
     const exitCode = await runTests({
       extensionDevelopmentPath,
       extensionTestsPath,
+      version: process.env.VSCODE_VERSION || "stable",
       launchArgs: [
         "--disable-extensions",
         `${extensionDevelopmentPath}/sampleWorkspace/sampleWorkspace.code-workspace`,

package/src/language-server/config/cache-busting-resolver.js

@@ -1,7 +1,62 @@
 // @ts-check
 const { pathToFileURL } = require("node:url");
 
-/** @import { ResolveContext, ResolutionResult, LoadResult, ImportContext } from "./cache-busting-resolver.types" */
+/** @import { ResolveContext, ResolutionResult, LoadResult, ImportContext, ImportAttributes, ImportAssertions, LegacyResolveContext, LegacyImportContext, Format } from "./cache-busting-resolver.types" */
+
+/**
+ * importAssertions was renamed to importAttributes after following versions of Node.js.
+ * Once we hit a minimum of v1.92 of VSCode, we can remove the legacy check and
+ * use `importAttributes` directly.
+ *
+ * - v21.0.0
+ * - v20.10.0
+ * - v18.19.0
+ *
+ * @see https://github.com/apollographql/vscode-graphql/issues/225
+ * @see https://nodejs.org/docs/latest/api/module.html#resolvespecifier-context-nextresolve
+ *
+ * @param {ResolveContext|ImportContext|LegacyResolveContext|LegacyImportContext} context
+ * @returns {context is ResolveContext|ImportContext}
+ */
+function isImportAttributesAvailable(context) {
+  return "importAttributes" in context;
+}
+
+/**
+ * @param {ResolveContext|ImportContext} context
+ * @returns {"importAttributes"|"importAssertions"}
+ */
+function resolveImportAttributesKeyName(context) {
+  if (isImportAttributesAvailable(context)) {
+    return "importAttributes";
+  }
+  return "importAssertions";
+}
+
+/**
+ * @param {ResolveContext|ImportContext|LegacyResolveContext|LegacyImportContext} context
+ * @returns {ImportAttributes|ImportAssertions}
+ */
+function resolveImportAttributes(context) {
+  if (isImportAttributesAvailable(context)) {
+    return context.importAttributes;
+  }
+  return context.importAssertions;
+}
+
+/**
+ * @param {ImportAttributes|ImportAssertions} importAttributes
+ * @returns {Format|null}
+ */
+function resolveConfigFormat(importAttributes) {
+  const [as, format] = importAttributes.as
+    ? importAttributes.as.split(":")
+    : [];
+  if (as === "cachebust" && format) {
+    return /** @type {Format} */ (format);
+  }
+  return null;
+}
 
 /**
  * @param {string} specifier
@@ -21,14 +76,16 @@ function bustFileName(specifier) {
  * @returns {Promise<ResolutionResult>}
  */
 async function resolve(specifier, context, nextResolve) {
-  if (context.importAttributes.as !== "cachebust") {
+  const importAttributes = resolveImportAttributes(context);
+  const format = resolveConfigFormat(importAttributes);
+  if (!format) {
     return nextResolve(specifier, context);
   }
   // no need to resolve at all, we have all necessary information
   return {
     url: bustFileName(specifier),
-    format: context.importAttributes.format,
-    importAttributes: context.importAttributes,
+    format,
+    [resolveImportAttributesKeyName(context)]: importAttributes,
     shortCircuit: true,
   };
 }
@@ -41,13 +98,19 @@ async function resolve(specifier, context, nextResolve) {
  * @returns {Promise<LoadResult>}
  */
 async function load(url, context, nextLoad) {
-  if (context.importAttributes.as !== "cachebust") {
+  const importAttributes = resolveImportAttributes(context);
+  const format = resolveConfigFormat(importAttributes);
+  if (!format) {
     return nextLoad(url, context);
   }
+  const contents =
+    "contents" in importAttributes
+      ? importAttributes.contents
+      : Object.keys(importAttributes).find((key) => key != "as");
   return {
-    format: context.format || "module",
+    format,
     shortCircuit: true,
-    source: context.importAttributes.contents,
+    source: /** @type {string} */ (contents),
   };
 }
 

package/src/language-server/config/cache-busting-resolver.types.ts

@@ -2,13 +2,20 @@ import { pathToFileURL } from "node:url";
 
 export type ImportAttributes =
   | {
-      as: "cachebust";
+      as: `cachebust:${Format}`;
       contents: string;
       format: Format;
     }
   | { as?: undefined };
 
-type Format =
+export type ImportAssertions =
+  | {
+      as: `cachebust:${Format}`;
+      [key: string]: string;
+    }
+  | { as?: undefined };
+
+export type Format =
   | "builtin"
   | "commonjs"
   | "json"
@@ -17,12 +24,23 @@ type Format =
   | null
   | undefined;
 
+export interface LegacyResolveContext {
+  conditions: string[];
+  importAssertions: ImportAssertions;
+  parentURL?: string;
+}
+
 export interface ResolveContext {
   conditions: string[];
   importAttributes: ImportAttributes;
   parentURL?: string;
 }
 
+export interface LegacyImportContext {
+  conditions: string[];
+  importAssertions: ImportAssertions;
+  format: Format;
+}
 export interface ImportContext {
   conditions: string[];
   importAttributes: ImportAttributes;

package/src/language-server/config/loadTsConfig.ts

@@ -3,16 +3,19 @@ import { dirname, extname } from "node:path";
 import typescript from "typescript";
 import { pathToFileURL } from "node:url";
 import { register } from "node:module";
-import { ImportAttributes } from "./cache-busting-resolver.types";
+import {
+  ImportAssertions,
+  ImportAttributes,
+} from "./cache-busting-resolver.types";
 // implementation based on https://github.com/cosmiconfig/cosmiconfig/blob/a5a842547c13392ebb89a485b9e56d9f37e3cbd3/src/loaders.ts
 // Copyright (c) 2015 David Clark licensed MIT. Full license can be found here:
 // https://github.com/cosmiconfig/cosmiconfig/blob/a5a842547c13392ebb89a485b9e56d9f37e3cbd3/LICENSE
 
-if (process.env.JEST_WORKER_ID === undefined) {
+try {
   register(
     pathToFileURL(require.resolve("./config/cache-busting-resolver.js")),
   );
-} else {
+} catch {
   register(pathToFileURL(require.resolve("./cache-busting-resolver.js")));
 }
 
@@ -93,7 +96,8 @@ export const loadJs: Loader = async function loadJs(filepath, contents) {
     if (
       error instanceof Error &&
       // [ERROR] ReferenceError: module is not defined in ES module scope
-      error.message.includes("module is not defined")
+      // [ERROR] ReferenceError: require is not defined in ES module scope
+      error.message.includes("is not defined in ES module scope")
     ) {
       return loadCachebustedJs(filepath, contents, "commonjs");
     } else {
@@ -113,10 +117,15 @@ async function loadCachebustedJs(
       // @ts-ignore
       {
         with: {
-          as: "cachebust",
+          as: `cachebust:${type}`,
           contents,
           format: type,
         } satisfies ImportAttributes,
+        assert: {
+          as: `cachebust:${type}`,
+          contents,
+          format: type,
+        } satisfies ImportAssertions,
       }
     )
   ).default;