👀 Extension Architecture / API

[jasonplatts]

Overview

Support for extensions is planned for a future release of CodeEdit. The extension system will provide similar capabilities to that of other editors.

Contributing

If you wish to contribute to building the CodeEdit extension architecture, please see the tasks below and review the relevant parts of the API documentation repository. This documentation should be used as the guide for development.

PLEASE NOTE THE DOCUMENTATION IS STILL WORK IN PROGRESS. TASKS AND THEIR RELATED GITHUB ISSUES WILL BE UPDATED AS THE RELEVANT DOCUMENTATION IS COMPLETED.

Each API feature functionality first needs to be built into CodeEdit so that it can be used internally by the application and then later exposed to extensions through the API.

Tasks

• 💬 Determine Extension Architecture #180
• ✨ Extension Store #183
• ✨ Snippets #167
• 🐞 Selecting text and then pressing delete key deletes selection and one character preceding selection CodeEditTextView#32
• ✨ Hover Provider Extension API #391
• ✨ Commands #222
• ✨ Tree Data Provider (Sidebar Tree View Content) #220
• Fix Marked Text Input CodeEditTextView#40
• ✨ Keybindings #224
• ✨ Tasks (Run scripts in the shell) #262
• ✨ Debugger Extension API #392
• Data Storage
• Display Notifications
• Themes
• Custom UI support with React Components
• Extension Debug Console
• ✨ Help Documentation #107

References

• Atom Extension API
• VS Code Extension API
• VS Code Extension Examples
• Raycast Extension API
• Nova Extension API
• Sketch Extension API

[jaydenseric]

If extensions have a JS API, it would be great if they can be standard ESM instead of CJS like Nova requires for its extensions:

https://docs.nova.app/extensions/#javascript-modules

CJS makes it tricky (but not impossible) to author extensions using Deno or other standards-aligned tooling without introducing a build step.

[jaydenseric]

Related: CodeEditApp/CodeEditTextView#40 .

[jasonplatts]

Hi @jaydenseric.

Thanks for joining the discussion. @austincondiff and I talked about this and it has been brought up in our Discord too.

Since it is early in the development, no decisions have been made in relation to the extension architecture. JavaScript Core (https://developer.apple.com/documentation/javascriptcore) has been mentioned as a possible option for implementing extensions. Unfortunately, as far as I am aware, it does not support ESM.

Having developed some extensions for Nova, I know this has been a frustration shared by other devs too. And, hopefully we can find a final solution that supports ESM. We also have an extensions channel in our Discord if you would like to get involved in the conversation.

[chriskrycho]

Whether or not the host environment supports ESM, it should be straightforward to provide a standard bit of boilerplate to make bundling it into a version which handles module scopes etc. easy for end user developers. (I'm happy to provide some input that way if/as you get there; just ping me about it!) Related: please do what Nova has not yet done and build your JS API in TypeScript and shipping types natively. (I'm also happy to advise on that!)

[austincondiff]

@chriskrycho That would definitely be ideal for a JS/TS API. We'd love to hear what you had in mind!

[TheBlckbird]

What about an extension system via WebAssembly? You could use WasmKit.

[TheBlckbird]

If extensions have a JS API, it would be great if they can be standard ESM instead of CJS like Nova requires for its extensions:

https://docs.nova.app/extensions/#javascript-modules

CJS makes it tricky (but not impossible) to author extensions using Deno or other standards-aligned tooling without introducing a build step.

How do you plan to run the JS? Cuz if you were using Bun, the whole CJS/ESM thing wouldn’t be such a problem, since Bun supports both, even in the same file.

[nervenes]

I'd also recommend WASM instead, most new editors seems to take this route (Zed, Lapce, Helix etc..), and for a reason.