monaco-languageclient
monaco-languageclient copied to clipboard
Error in Angular Example : Unable to load extension-file://vscode.theme-defaults/extension/themes/dark_modern.json: Not Found
Can you please format your issue, use a code block and explain a little bit more what is happening to you?
Can you please format your issue, use a code block and explain a little bit more what is happening to you? I have cloned the latest code form repository and, when running angular code form verify folder , I am encountering the following error in the console:
@CGNonofr this is the same problem we saw here. I don't have a solution for it, yet. The existing esbuild plugin you provide does not work as is in angular. Everything I tried so far did not work, but it also did not spend much time.
Ok 🤔 Can you please create an issue on the monaco-vscode-api side with a minimal reproduction repo?
@CGNonofr is this sufficient? https://github.com/TypeFox/monaco-languageclient/tree/main/verify/angular
Oh you mean it's not working in the demo here!
Yes, and the angular setup is already there. Just do: npm run verify in the directory. The verification examples are all independent packages. That run command will bring up the ng dev server on port 4200
@CGNonofr any updates on this?
Not yet, it's in my backlog
I've had a look, there is NO WAY to inject a load esbuild plugin because angular injects its own angular-compiler first to load all files, and esbuild doesn't support transforming files except while loading it
@CGNonofr thank you, so there is no way to make the stack work with ng dev server?
@CGNonofr thank you, so there is no way to make the stack work with ng dev server?
I'm not exactly sure what is possible. It seems that esbuild is used directly, and that vite can be used instead, isn't it?
There is always a way though ^^ I've managed to make it work by patching the angular-compiler, so we can still hack it using patch-package
I'm not exactly sure what is possible. It seems that esbuild is used directly, and that vite can be used instead, isn't it?
Did you find good documentation on it?
There is always a way though ^^ I've managed to make it work by patching the angular-compiler, so we can still hack it using patch-package
🚀
Did you find good documentation on it?
Not really, I've only seen mentions of it, also ChatGPT talked about it, totally unclear to me though
🚀
Do you want me to create a PR with the hack?
totally unclear to me though
You are not the only one.
Do you want me to create a PR with the hack?
@CGNonofr yes, but how long will that last?
Yes, I meant that
Probably not really... we should probably investigate the vite alternative before
@CGNonofr Yes, that would be best, but I haven't found a way/documentation how to achieve that, yet. Maybe the angular tooling nx provides is a way out/forward.
My understanding is that Angular uses esbuild directly, and vite is only used as a dev server, i.e. not for building and not at all in production builds. But, like it is possible to directly configure webpack using a custom builder, the same is available for esbuild: https://www.npmjs.com/package/@angular-builders/custom-esbuild I don't know if you can inject the esbuild plugins you want through that, but it does mention loading esbuild plugins.
I don't know if you can inject the esbuild plugins you want through that, but it does mention loading esbuild plugins.
Hi @jhk-mjolner I tried this already, but without success and I think the reason for this is what @CGNonofr mentioned: "injects its own angular-compiler first to load all files, and esbuild doesn't support transforming files except while loading it"
@CGNonofr I just had an idea: Is it possible to auto-transform all json assets to js. I see that you already make use of @rollup/plugin-json. The we could completely prevent the problem. I don't know the implications of this idea, but maybe it is not as immersive as may seem. WDYT?
@CGNonofr I just had an idea: Is it possible to auto-transform all json assets to js. I see that you already make use of
@rollup/plugin-json. The we could completely prevent the problem. I don't know the implications of this idea, but maybe it is not as immersive as may seem. WDYT?
It's not possible, some assets are loaded directly by VSCode, or even directly used in the HTML (like images, css, fonts...). And we can't cheat using glob urls because assets can be used in multiple contexts (main thread or in the extension host worker)
@CGNonofr ok, that is the caveat. Is it possible to statically analyse the code related imports and treat them differently at least. I know this would lead to duplication. The least bundlers need to mess with things, the easier it will be to integrate the packages.
Is it possible to statically analyse the code related imports and treat them differently at least
I have no idea what you mean 🤔
I have no idea what you mean 🤔
I was thinking about theme instructions or language configuration, but I guess that is not the correct way. It is just frustrating that frameworks like angular or next and their tooling like to throw stones at you if you want to achieve something that does fit their regime.
Instead of patching the lib, I vote for submitting a PR on their side (:
I'm aware of the issue with angular, but what about next?
Regarding next, that was just a general remark, because if you want to use this stack you have to load everything dynamically. At least you can configure their webpack tooling directly.
Instead of hiding a bundler in their framework they should provide tools/plugins to integrate what the need into existing tools. You have to solve some many problems, because of bad tooling infrastructure design decisions.
The next issues are not related to assets though, so only angular has issues with it