I’ve put together a small editor that can write content to the filesystem. The API is only supported by chrome, though it’s so cool that Yjs allows you to proxy those writes to other browsers.
It’s my first time using Yjs, and I love it! It’s a real game-changer to have this kind of functionality so easily available for developers. I’m looking forward to using it for some other things in the future.
Fyi, the one issue I hit was with the Monaco binding, because I was loading in the library in a pretty weird way. So I copied y-monaco into my project and hacked my way around it.
I feel you… setting up Monaco is quite a hassle… I use monaco as a bundle exporting named exports. The demo code (also using webpack) works as expected. https://github.com/yjs/yjs-demos/tree/master/monaco
So I do import * as monaco from 'monaco-editor'. This is, I think, the correct way to import monaco. Module bundlers often try to support both: named exports and default exports. This often leads to issues.
Your module bundler might fail because it expects a module with a default export. I.e. import monaco from 'monaco-editor'.
In a different place you import monaco like this: import type TMonaco from 'monaco-editor'. This will probably trigger your module bundler to use the default export instead of the named exports. However, I use monaco as a named export. As said, you just can’t use both.
You could try import * as TMonaco from 'monaco-editor' instead and see if this fixes the problem. Named exports are much cleaner and allow your module bundler to strip unused functions (dead-code elimination).
I ran into a few problems before because I’m using snowpack (as well as webpack ), so I think I hit a combo of problems. Though seems you’re right - I wasn’t importing properly, so I’ll give that a try.
), so I think I hit a combo of problems. Though seems you’re right - I wasn’t importing properly, so I’ll give that a try.