Enhancements to Acode Plugin installer

[alMukaafih]

Is it possible to add support for plugin dependencies?

[bajrangCoder]

Clearly explain it in detail

[alMukaafih]

Like an array of plugins in plugin.json to be Installed along with the plugin. Maybe something like

{
  "dependencies": [
    "bajrangcoder.acodex", "sebastianjnuwu.acode.eruda"
  ]
}

[alMukaafih]

I am willing to assist in implementing this

[bajrangCoder]

Like an array of plugins in plugin.json to be Installed along with the plugin. Maybe something like

{
  "dependencies": [
    "bajrangcoder.acodex", "sebastianjnuwu.acode.eruda"
  ]
}

Ok

[bajrangCoder]

I am willing to assist in implementing this

Contributions are welcomed ☺️, feel free to open pr

[sebastianjnuwu]

I am willing to assist in implementing this

Contributions are welcomed ☺️, feel free to open pr

I had already talked about this, the system is similar to that of vscode, the .acode folder has the settings and dependencies and acode recognizes itself when the project folder is open if not with the default

I tried to do it, but I had some problems regarding recognizing the file and downloading the plugins. The paid plugins gave an error when downloading since they have a different API logic.

[alMukaafih]

Currently when updating Plugins the installer does not delete the previous installation of the plugin rather it installs the update over the current installation. There is a problem of redundant files.
Suppose this is the current installation

.
├── assets
│   ├── 0.svg
│   ├── 1.svg
│   └── 2.svg
├── icon.png
├── main.js
├── plugin.json
└── readme.md

and this is the update

.
├── assets
│   ├── 3.svg
│   ├── 4.svg
│   └── 5.svg
├── icon.png
├── main.js
├── plugin.json
└── readme.md

after updating this will be the current installation

.
├── assets
│   ├── 0.svg
│   ├── 1.svg
│   ├── 2.svg
│   ├── 3.svg
│   ├── 4.svg
│   └── 5.svg
├── icon.png
├── main.js
├── plugin.json
└── readme.md

[alMukaafih]

I suggest using a combination of id and version as the plugin folder name

`${plugin.id}-${plugin.version}`

instead of just id

[bajrangCoder]

Nice, I haven't noticed this.

I suggest using a combination of id and version as the plugin folder name

I think it will be good to remove the previous folder and then add the new update one , as the the id and version combination will make different instances of same plugin.

If you have any better idea then please share

[alMukaafih]

Nice, I haven't noticed this.

I suggest using a combination of id and version as the plugin folder name

I think it will be good to remove the previous folder and then add the new update one , as the the id and version combination will make different instances of same plugin.

If you have any better idea then please share

Removing the previous folder and then installing the update will introduce some latency when updating a plugin, while this might go unnoticed for plugins with few files for plugins with close to a thousand files it will be noticed. We can keep a mapping of plugin IDs to their folders.

[bajrangCoder]

Actually that latency will be visible in other approaches too.
I found a new way: "Checksum-Based Update (Detect Changes Before Overwriting)" this will only call few fs calls based on update (which will be efficient)

[alMukaafih]

What about obsolete files? How do we detect them?

[bajrangCoder]

We can detect it:
By comparing the files present in the current plugin installation with the files in the update package. If any file exists in the current installation but does not exist in the update package, it is considered obsolete and can be safely deleted.

[alMukaafih]

We can detect it: By comparing the files present in the current plugin installation with the files in the update package. If any file exists in the current installation but does not exist in the update package, it is considered obsolete and can be safely deleted.

Yes this is better, because some plugins assume the plugin folder to be it's id

[alMukaafih]

I will begin working to implement this