wakaru IDE

[0xdevalias]

Figured I would split this off into a new issue so it doesn't flood the last unrelated issue too much.

---

Are you able to tell us more about your plan/roadmap with it, and what you're hoping it will allow/enable?

@0xdevalias I have created a package /packages/ide which provides a vscode-like experience. I want to use it to replace the existing playground. I am still trying to figure out the idea haha.. Module mapping won't be exposed, instead, you can directly edit the filename in the file explore. And two tabs will be provided for the compare view, which you can drag and organize in any form you like. 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.

Originally posted by @pionxzh in #35 (comment)

[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):

• add Chrome DevTools extension that allows the web IDE to be used within DevTools #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

[pionxzh]

fs and path were all shimmed.