monaco-languageclient: TS Compilation errors export 'IFileService' (imported as 'IFileService') was not found

I am following recommendations about editor + LC usage and cannot compile project.

  1. Imports styles on my project looks like this (only 2 kinds), they used only as typescript typings import * as Monaco from 'monaco-editor/esm/vs/editor/editor.api'; import { editor } from 'monaco-editor/esm/vs/editor/editor.api';

  2. Main editor package is importing asyncronious via bootstrap function like this

/** Bootrapping only once time */
let monacoInstanceRequest: Promise<MonacoInstance>;

export async function bootstrapMonacoPackage(): Promise<MonacoInstance> {
	if (!monacoInstanceRequest) {
		monacoInstanceRequest = new Promise(async (resolve: (monaco: MonacoInstance) => void) => {
			const localePackage = await getLocalePackage(window.language);

			if (localePackage) {
				setLocaleData(localePackage);
			}

			const monaco = await import(/* webpackChunkName: "monaco.editor" */	'monaco-editor/esm/vs/editor/editor.api.js');

			configure(monaco);
			resolve(monaco);
		});
	}

	return monacoInstanceRequest;
}
  1. Versions
"monaco-editor": "0.41.0"
"monaco-languageclient": "6.4.0"
"vscode-languageclient": "~8.1.0"
"vscode": "npm:@codingame/monaco-vscode-api@~1.81.1"
"typescript": "5.0.4"

Compilation errors:

image

image

And a lot of other typings error (1000+)

I am using webpack + typescript. No aliases inside of webpack for the vscode-api

About this issue

  • Original URL
  • State: closed
  • Created 10 months ago
  • Comments: 36 (1 by maintainers)

Most upvoted comments

monaco-vscode-api imports statically monaco-editor, so there’s not point for you to import dynamically monaco-editor

What you should do is doing all the monaco stuff in a module, and import that module dynamically

⬆️ “Try to remove theme and textmate services.”

@BusinessDuck Enabling textmate disables monarch support in monaco-editor. Try to remove theme and textmate services. (@CGNonofr correct me if I am wrong, but that did not change, right?).

We are in the process of improving documentation. Here and in monaco-vscode-api

@CGNonofr and @BusinessDuck We may use peerDependency wrong then or yarn 1 is just too old (depends on your point of view 🙂 ). A peerDependency defines a requirement for a “versions range” (that may be specific to a single version) that should be met. It was invented for plugins (see link below), but can be used to flag dependency version problems. With regular dependencies npm decides for you which dependency wins if you have different versions of the same dependency in your dependency hierarchy (does anyone have details on that?).

If a peerDependency is not met at all, npm install it by default (also see link). So, everyone using npm 7+ won’t face a problem. Tools do the same thing, but don’t do the same thing. 😉 There is this field peerDependenciesMetain the package.json (used in the client) that allows to specifies optional. Question again is: Does your package manager respect that or just doesn’t know. There is a reason why we use the engines field in the client as well:

"peerDependenciesMeta": {
  "monaco-editor": {
    "optional": false
  },
  "vscode": {
    "optional": false
  }
}

So, it is not necessarily about being optional, e.g. if I remove the monaco-editor as peerDependency from monaco-vscode-api everything falls apart.

The initial post is fairly old, but it was updated with newer information (the information is still valid, I think): https://nodejs.org/es/blog/npm/peer-dependencies

Does this help or introduce even more confusion?