Repository navigation
👀 Extension Architecture / API #76
Copy link
Copy link
Open
Labels
PRIORITYThis issue has priority over other issues.This issue has priority over other issues.clarification neededFurther information is requestedFurther information is requestedenhancementNew feature or requestNew feature or requestextensionsIssues related to the extension architecture in CodeEditIssues related to the extension architecture in CodeEdithelp wantedExtra attention is neededExtra attention is needed
Description
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
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
PRIORITYThis issue has priority over other issues.This issue has priority over other issues.clarification neededFurther information is requestedFurther information is requestedenhancementNew feature or requestNew feature or requestextensionsIssues related to the extension architecture in CodeEditIssues related to the extension architecture in CodeEdithelp wantedExtra attention is neededExtra attention is needed
Type
Projects
- StatusShow more project fields📋 Todo
Activity
jaydenseric commentedon Mar 21, 2022
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 commentedon Mar 21, 2022
Related: CodeEditApp/CodeEditTextView#40 .
jasonplatts commentedon Mar 21, 2022
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.
[-]Add Extension API[/-][+][FEAT] - Add Extension API[/+][-][FEAT] - Add Extension API[/-][+][FEAT] Extension API[/+][-][FEAT] Extension API[/-][+]✨ Extension API[/+][-]✨ Extension API[/-][+]✨ Extension Architecture / API[/+][-]✨ Extension Architecture / API[/-][+]👀 Extension Architecture / API[/+]chriskrycho commentedon Oct 5, 2023
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 commentedon Oct 5, 2023
@chriskrycho That would definitely be ideal for a JS/TS API. We'd love to hear what you had in mind!
TheBlckbird commentedon Jan 13, 2024
What about an extension system via WebAssembly? You could use WasmKit.
TheBlckbird commentedon Jan 13, 2024
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.
Bart-Jan commentedon Apr 28, 2025
(Also?) supporting WASM Sounds interesting…
That way I could use Swift to create extensions (Java-/Type-script is always a mixed blessing for me, but that’s just me, right!).
Also security/enterprise wise that might be better in the long run?!
Just my 2c.