wakaru IDE about wakaru

[pionxzh]

fs and path were all shimmed.

[0xdevalias]

I have created a package /packages/ide which provides a vscode-like experience.

@pionxzh Cool, shall dig into it and have a look when I get a chance :)

---

I want to use it to replace the existing playground

@pionxzh Makes sense. I've seen similar sorts of things done for the playgrounds of other projects (eg. swc-project/swc-playground, sxzz/ast-explorer, etc) like this (though with quite a cut down version of monaco), and it seemed to work quite well.

Ultimately I think it would depend how complex/hard to use the IDE version of things gets. If it gets too advanced, I could still see the potential value in having a 'simple playground' view still (even if that's still using monaco, but with some of the 'more advanced' bits hidden/etc)

---

I am still trying to figure out the idea haha..

@pionxzh Haha, yeah, makes sense. If you want to bounce some ideas about it sometime; happy to read your thoughts and share my /2c about it; as it seems what you're doing with wakaru is touching on a lot of areas that i've thought about/wanted to build myself over the years (but never quite got around to it)

---

Module mapping won't be exposed, instead, you can directly edit the filename in the file explore.

@pionxzh Hrmm.. fair. I like the idea of being able to directly edit the filename in the file explorer for 'ease of use' in the UI, but I would personally be kind of sad if the 'module mapping' concept was removed entirely.

My main use case would be to unpack/unminify a large code bundle once, and commit that to a git repo to keep track of history; then when there are future bundle releases, unpack/unminify each of those in the same way. The 'module mapping' seems like a good way to maintain some of the 'manual analysis/renaming' steps that could be reused when processing a future version of the bundle; which feels like it would be lost (and therefore be a more manual process each time) if the 'module mapping' was lost

---

And two tabs will be provided for the compare view, which you can drag and organize in any form you like.

@pionxzh Not sure I fully follow this part fully; so I'll have to dive into the code and/or wait to see how it turns out.

---

The editor would be Monaco, which offers a better editing experience. Features like download, better unminify handling, error reporting...

But I might drop the idea and simply put Monaco into the existing playground.

@pionxzh Yeah, I definitely like the idea of using Monaco. It seems like it can enable some super powerful experiences.

Simpler stuff like syntax highlighting/etc will definitely be nice; but what i'm truly interested and excited for in using something like Monaco for an 'unpack/unminify IDE' is the ability to have things like 'go to symbol' / 'rename symbol' / etc:

• https://code.visualstudio.com/docs/editor/editingevolved
  • Go to Definition: https://code.visualstudio.com/docs/editor/editingevolved#_go-to-definition
  • Go to Type Definition: https://code.visualstudio.com/docs/editor/editingevolved#_go-to-type-definition
  • Go to Implementation: https://code.visualstudio.com/docs/editor/editingevolved#_go-to-implementation
  • Go to Symbol: https://code.visualstudio.com/docs/editor/editingevolved#_go-to-symbol
  • Open Symbol by Name: https://code.visualstudio.com/docs/editor/editingevolved#_open-symbol-by-name
  • Reference Information: https://code.visualstudio.com/docs/editor/editingevolved#_reference-information
  • Rename Symbol: https://code.visualstudio.com/docs/editor/editingevolved#_rename-symbol
  • Inlay Hints: https://code.visualstudio.com/docs/editor/editingevolved#_inlay-hints
  • etc

This was another semi-related project I came across when I was exploring using Monaco:

• https://github.com/microsoft/vscode-anycode

  • Anycode A Tree-sitter-based language extension that inaccurately implements popular features like "Outline & Breadcrumbs", "Go to Symbol in Workspace", "Document Highlights" and more. This extension should be used when running in environments that don't allow for running actual language services, like https://github.dev/ or https://vscode.dev/.

  • https://microsoft.github.io/monaco-editor/typedoc/interfaces/languages.DocumentSymbolProvider.html

---

Edit: And here is an idea i've been wanting to play around with, using monaco as the basis for a Chrome DevTools Extension that enhances the functionality of the 'Sources' tab (or creates a new tab that is like 'Sources++', and supports 'go to declaration', etc):

• #76

[0xdevalias]

@pionxzh Was just skimming through some of the IDE code, and left some notes:

• 3ca0d39#r133011789
  • RE: using React's createContext in useEventEmitter.ts + some memoisation improvements
• 3ca0d39#r133012145
  • RE: import path from 'node:path' and whether it will be shimmed/polyfilled for a web environment