-
-
Notifications
You must be signed in to change notification settings - Fork 13
Conversation
New next versions are available: These version use |
@cdietrich your opinion or review of the react component changes would be helpful. 🙂 |
will need to when when i find time to look. maybe tomorrow |
No rush, sounds good. 👍 |
in a first step i just bumped. this gives
any idea? |
npm run dev gives
|
@cdietrich did you check this (from second comment):
|
i have these in my package.json.
|
Now you need to define the overrides for any sub-dependencies to be inline. Just do it as done here:
|
ok, is there an easy way to find out which service package has which missing dependency |
just adding the overrides and resolutions does not help |
When I do that it works |
missing is not the problem. mismatch versions are the problem. Sorry, this produces another hick-up, but the other approach was worse, because it the patching/treemending monaco-editor was hidden from the user/project. Now it is explicitly required/stated |
problem is that it still does not work. |
It is a mess. I am moving between noob or expert every day. 😆 Remove everything from your checkout ( diff --git a/package.json b/package.json
index 3bee246..4494b8d 100644
--- a/package.json
+++ b/package.json
@@ -15,6 +15,7 @@
"@codingame/monaco-vscode-files-service-override": "^1.83.5",
"@typefox/monaco-editor-react": "^2.4.0-next.2",
"monaco-editor-workers": "^0.44.0",
+ "monaco-editor": "npm:@codingame/monaco-editor-treemended@>=1.83.5 <1.84.0",
"react": "^18.2.0",
"react-dom": "^18.2.0",
"vscode": "npm:@codingame/monaco-vscode-api@^1.83.5" |
yes -fdx helped me too. |
I add that as npm script in most projects now. |
i wonder if we can make the or something else where i can hook in and have access to maybe optional parameter on onLoad callback? |
Good idea. I will do that |
good with that i can check for changes of
|
Pushed an update an new |
cool that worked. as monaco will be started i dont need to close old docs |
@cdietrich can I reproduce this with your above repo? |
Yea if you use the recently updated branch |
@cdietrich I can re-produce the issue with your example. The comparison only works properly for simple properties. That should be re-producible by a unit test (=fix template). Will do it with this PR, too. Thank your for spotting this. |
As you can see the test fails now ⬇️ |
@cdietrich The comparison problem is resolved: |
nice and thanks. works fine |
…om monaco-lnaguageclient
8c6d819
to
d2279d1
Compare
b83aa34
to
d38568d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some general feedback. In particular I would be a fan of renaming start
to initAndStart
(or something similar to convey the two steps being a part of that). startNoInit
can be just start
then, which implicitly requires init
to be run before.
Some function headers on the new methods would be helpful for other users as well, so that the intention of the new API is clearly outlined.
Local tests & double checking the examples look good by the way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One last thing, noInitJustStart
can probably be start
, and then the function header makes it clear that this doesn't init (or requires init to be invoked first).
Thank you @montymxb I merged it after performing the latest changes. I want to included the latest |
This allow to init and start the wrapper in two steps (from #56).
Using just
start
is still considered the default.This changes enforces to
dispose
otherwiseinit
will throw an exception.This is integrated in the react component as well now. Most method are now protected, so a derived component can override the
handleReinit
,destroyMonaco
,initMonaco
orstartMonaco
.isReInitRequired
was extracted frominitMonaco
and made protected to allow overriding it.