You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[README for JavaScript-related code](../src/README.md) | [README for Rust-related code](../src-tauri/README.md) | Contributing Guidelines
2
+
1
3
# Contributions Guidelines
2
4
3
5
## Note
@@ -10,19 +12,39 @@ Translations are done externally via a [Kaede Translations repository](https://g
10
12
11
13
## Extensions
12
14
13
-
tbd
15
+
You need this section only if you want to develop an extension.
16
+
17
+
### Repositories
18
+
19
+
Kaede has two built-in plugin repositories.
20
+
21
+
The first one is a [Kaede Add-ons User Repository (KAUR)](https://github.com/kaede-basement/kaur), similar to [AUR](https://aur.archlinux.org/) and [nixpkgs](https://github.com/NixOS/nixpkgs). This repository contains user published extensions.
22
+
23
+
The second one is a [trusted-extensions repository](https://github.com/kaede-basement/trusted-extensions). I publish my extensions there. Others may publish there too, but only by contacting me. A plugin publisher must provide me the plugin source code and build manuals. I will manually review the provided code and provide the feedback if something is not good. The reviewing procedure will happen each time a plugin publisher wants to update their extension in the repository.
24
+
25
+
### Safety
26
+
27
+
Extensions can be loaded in two environments.
28
+
29
+
The first one is a restricted environment (sandbox) that uses a permission-based system. When enabling the plugin for the first time, users are prompted with the permissions window. That window has permission toggles that the plugin requested. KAUR extensions are executed in this environment.
30
+
31
+
Restricted environment is achieved by using a [Secure ECMAScript](https://github.com/endojs/endo) framework. Each permission has its own list of globals that are passed to the plugin. Unfortunately, almost every DOM operation is prohibited since it leads to the sandbox escape.
32
+
33
+
The second one is an unrestricted environment that allows plugins to do everything that the Kaede can do itself. Trusted extensions are executed in this environment. Settings also have an option to enable the execution of KAUR extensions that require an unrestricted environment.
14
34
15
35
## Code Formatting
16
36
17
37
All files are formatted with [ESLint](https://eslint.org/) using the configuration in `eslint.config.js`. Ensure it is run on changed files before committing!
18
38
19
39
Please also follow the project's conventions for frontend:
20
40
41
+
- No AI slops in the launcher code (plugins don't count).
21
42
- TypeScript is highly recommended.
22
43
-`.vue` file names should be formatted as `PascalCase`. All other files should use `kebab-case`.
23
44
- Exported constants should be formatted as `PascalCase`.
24
45
- Functions, variables, non-exported constants should be formatted as `camelCase`.
25
-
- Elements styling is preferred by using `Tailwind v3` classes. If there is no utility class for some case, make your own, or use CSS/JS.
46
+
- Element styling is preferred by using `Tailwind v3` classes. If there is no utility class for some cases, then make your own with CSS.
47
+
-[BEM](https://en.bem.info/methodology/) methodology is the preferred way to name element IDs and classes to simplify styling by extensions. All elements should have unique IDs.
26
48
27
49
## Commit Messages
28
50
@@ -33,24 +55,24 @@ Please also follow the project's conventions for frontend:
33
55
### Elements
34
56
35
57
-**Type**: Choose from the following list. If none of the types match, use `chore`.
36
-
-`feat`: A new feature
37
-
-`fix`: A bug fix
38
-
-`docs`: Documentation only changes
39
-
-`style`: Changes that do not affect the meaning of the code
40
-
-`refactor`: Improving code structure
41
-
-`perf`: A code change that improves performance
42
-
-`test`: Adding missing tests or correcting existing tests
43
-
-`build`: Changes that affect the build system or external dependencies
44
-
-`chore`: Other changes that don't modify src or test files
45
-
-`revert`: Reverts a previous commit
46
-
-`release`: Releasing a new version
47
-
-`ci`: Changes to our CI configuration
58
+
-`feat`: A new feature.
59
+
-`fix`: A bug fix.
60
+
-`docs`: Documentation only changes.
61
+
-`style`: Changes that do not affect the meaning of the code.
62
+
-`refactor`: Improving code structure.
63
+
-`perf`: A code change that improves performance.
64
+
-`test`: Adding missing tests or correcting existing tests.
65
+
-`build`: Changes that affect the build system or external dependencies.
66
+
-`chore`: Other changes that don't modify src or test files.
67
+
-`revert`: Reverts a previous commit.
68
+
-`release`: Releasing a new version.
69
+
-`ci`: Changes to our CI configuration.
48
70
-**Scope**: As described in Conventional Commits.
49
71
-**Breaking Change**: If you're introducing a breaking change, append `!` to the type or scope, e.g., `feat(ui)!: Breaking change`.
50
72
51
73
-**Subject**: Brief description of the change.
52
74
53
75
### Guidelines
54
76
55
-
- Use imperative mood, e.g., "add feature" instead of "adding feature" or "added feature".
77
+
- Use imperative mood, e.g. "add feature" instead of "adding feature" or "added feature".
0 commit comments