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.
-
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';
-
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;
}
- 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:
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)
Right, here’s the fix: https://github.com/CodinGame/monaco-vscode-api/pull/166
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 🙂 ). ApeerDependency
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 dependenciesnpm
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 fieldpeerDependenciesMeta
in thepackage.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:So, it is not necessarily about being optional, e.g. if I remove the
monaco-editor
as peerDependency frommonaco-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?