Obtaining more information on why a published extension with a web target fails to load

[miqh]

Hello,

I'm unable to figure out why my theme-based extension can't be loaded in a web environment (e.g. vscode.dev). When trying to install it (it's a pre-release for now), I'm prompted with the following:

Clicking the "More Information" button takes me to a VS Code documentation page clarifying the conditions that need to be met for an extension to be available for a web environment.

I've reviewed these, but to no avail. Some things I've checked:

• package.json includes a browser property, which points to an extension entry point bundle specifically for the web.
  • https://github.com/miqh/vscode-core-theme/blob/master/package.json#L125
• The web extension entry point only makes use of vscode.ExtensionContext.globalState and vscode.window.showInformationMessage, both of which I assume should be safe in a web context.
  • https://github.com/miqh/vscode-core-theme/blob/master/src/extension.web.ts
• The extension codebase only has one contributed command with an enablement of !isWeb && coreTheme.devOnly. Note the latter is a custom when clause context that's only set when running the extension in development.
  • https://github.com/miqh/vscode-core-theme/blob/master/package.json#L38

Are there any other channels from which I can obtain more information on exactly why my web target of my extension refuses to load?

Any guidance would be much appreciated.

[alefragnani]

Hi @miqh ,

I'm not an expert in bundling, but I have noticed you are using esbuild to it, and comparing your build.mjs file with the sample provided by the documentation (here https://code.visualstudio.com/api/extension-guides/web-extensions#using-esbuild), I have noticed your script only outputs platform: "node", but not browser. I would suggest you to review the bundling script and the scripts section in package.json file, so it follows the requirements and guidelines.

    ...
    async function main() {
  const ctx = await esbuild.context({
    entryPoints: ['src/web/extension.ts', 'src/web/test/suite/extensionTests.ts'],
    bundle: true,
    format: 'cjs',
    minify: production,
    sourcemap: !production,
    sourcesContent: false,
    platform: 'browser',
    outdir: 'dist/web',
    external: ['vscode'],
    logLevel: 'warning',
    // Node.js global to browser globalThis
    define: {
      global: 'globalThis'
    },

    plugins: [
      polyfill.NodeGlobalsPolyfillPlugin({
        process: true,
        buffer: true
      }),
      testBundlePlugin,
      esbuildProblemMatcherPlugin /* add to the end of plugins array */
    ]
  });
    ...

package.json

  "scripts": {
    "vscode:prepublish": "npm run package-web",
    "compile-web": "npm run check-types && node esbuild.js",
    "watch-web": "npm-run-all -p watch-web:*",
    "watch-web:esbuild": "node esbuild.js --watch",
    "watch-web:tsc": "tsc --noEmit --watch --project tsconfig.json",
    "package-web": "npm run check-types && node esbuild.js --production",
    "check-types": "tsc --noEmit",
    "pretest": "npm run compile-web",
    "test": "vscode-test-web --browserType=chromium --extensionDevelopmentPath=. --extensionTestsPath=dist/web/test/suite/extensionTests.js",
    "run-in-browser": "vscode-test-web --browserType=chromium --extensionDevelopmentPath=. ."
  }

Hope this helps

[miqh]

Thank you for the reply @alefragnani.

Good catch with the platform build property, I'll tinker around to see whether having a dedicated browser configuration can make a difference in my case. I was reluctant to blindly copy the sample configuration verbatim because of the bloat it adds that I don't need.

I know it might be a stretch for you to answer, but are you aware of any other means of getting more diagnostic information when encountering the extension loading error I asked about originally? I feel like having a technical trace of some sort would definitely steer me in the right direction.

Update:

Embarrassingly, it never dawned on me to try slipping in some breakpoints on the web version of VS Code to see what was going wrong.

Shortly after probing around, I discovered that, for some odd reason, despite explicitly choosing the Install Pre-Release Version option on my extension, VS Code is loading an extension manifest payload that corresponds to the latest version that isn't a pre-release. Because it's doing this, I understand why the loading rejection occurs. That version didn't have web support at all.

https://github.com/microsoft/vscode/blob/5533614b42c04c1f4eaa50efcfeb97f5d8d6ae9f/src/vs/workbench/services/extensionManagement/common/extensionManagementService.ts#L512-L513

Although this does feel like a bug in VS Code to me, I speculate that it's probably an uncommon situation I find myself in, where I'm both trying to use a pre-release, and also adding web support that was never originally there in the extension. I expect that when I eventually publish a version that isn't a pre-release, that things should work, but time will tell as I continue to do some testing.

[alefragnani]

Hi @miqh ,

Good to know it was helpful. Hope you can apply the proper configuration for your extension.

I remember some questions when pre-release versions were launched, but not entirely sure if your scenario was discussed back then. The official documentation (https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions) does not refer anything specific on web platform, so it would work the same even on desktop. If that's not the case, maybe we have an issue on it, and you should report on VS Code repo (https://github.com/microsoft/vscode/issues) directly.

Hope this helps