Problem

When modern webpack-based tools bundle code that pulls in vscode-languageserver-types, they can still end up resolving the published UMD build:

• vscode-languageserver-types/lib/umd/main.js

That UMD wrapper triggers webpack's static-analysis warning:

Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

The warning is coming from the published UMD artifact itself, not from application code.

Why I think this should be fixed upstream

The package already publishes an ESM build:

• ./lib/esm/main.js

and the package metadata already partially acknowledges that:

{
  "main": "./lib/umd/main.js",
  "exports": {
    ".": {
      "browser": "./lib/esm/main.js",
      "import": "./lib/esm/main.js",
      "default": "./lib/umd/main.js"
    }
  }
}

However, in real bundler chains, consumers can still land on the UMD file and get the warning.

In my case, a docs build using Docusaurus/Webpack 5 pulled in this chain:

• @docusaurus/theme-mermaid
• mermaid
• html-standard
• vscode-css-languageservice
• vscode-languageserver-types

and webpack reported the warning from:

• vscode-languageserver-types/lib/umd/main.js

Evidence

Current published package metadata:

{
  "name": "vscode-languageserver-types",
  "version": "3.17.5",
  "main": "./lib/umd/main.js",
  "typings": "./lib/umd/main",
  "exports": {
    ".": {
      "browser": "./lib/esm/main.js",
      "import": "./lib/esm/main.js",
      "default": "./lib/umd/main.js"
    }
  }
}

Current UMD wrapper begins like this:

(function (factory) {
    if (typeof module === "object" && typeof module.exports === "object") {
        var v = factory(require, exports);
        if (v !== undefined) module.exports = v;
    }
    else if (typeof define === "function" && define.amd) {
        define(["require", "exports"], factory);
    }
})(function (require, exports) {

That packaging is what webpack warns on.

Webpack warning:

Critical dependency: require function is used in a way in which dependencies cannot be statically extracted

with module path matching:

vscode-languageserver-types/lib/umd/main.js

Workaround currently required downstream

The only reliable workaround I found was to explicitly alias the package to the ESM build:

resolve: {
  alias: {
    "vscode-languageserver-types$":
      require.resolve("vscode-languageserver-types/lib/esm/main.js"),
    "vscode-languageserver-types/lib/umd/main.js$":
      require.resolve("vscode-languageserver-types/lib/esm/main.js"),
  },
},
ignoreWarnings: [
  {
    message:
      /Critical dependency: require function is used in a way in which dependencies cannot be statically extracted/,
    module:
      /vscode-languageserver-types[\\/]lib[\\/]umd[\\/]main\.js/,
  },
]

After forcing the ESM entry, the warning disappears and the build succeeds normally.

That suggests the ESM artifact is already suitable, but the published package surface still makes it too easy for bundlers/dependencies to fall back to the UMD build.

Expected behavior

Modern bundlers should not need manual aliasing or warning suppression just to consume vscode-languageserver-types.

Actual behavior

Bundlers can still resolve the UMD build and emit webpack critical dependency warnings from the published artifact.

Request

Would you consider updating the published package shape so modern bundlers are less likely (or unable) to fall back to the UMD entry unintentionally?

Potential fixes could include one or more of:

1. Make the package root resolve to the ESM build for modern bundler scenarios more consistently.
2. Expose explicit subpath exports for ESM vs UMD/CJS instead of leaving default pointed at UMD.
3. Revisit whether main should still point at ./lib/umd/main.js.
4. Coordinate with downstream Microsoft language-service packages that still publish UMD-first metadata, if that is part of the chain here.

Notes

I realize some of the downstream resolution behavior may also involve vscode-css-languageservice (which still publishes main as UMD and module as ESM), so if maintainers think part of this belongs there instead, I’m happy to open a companion issue. But the webpack warning itself is currently emitted from the vscode-languageserver-types UMD artifact published from this repo.

Environment

• webpack 5
• Docusaurus v3.9.2
• Node v25.8.1
• vscode-languageserver-types 3.17.5