add a short explaining about plugins usages #7031
Conversation
test_plugin/README.md
Outdated
| [dependencies] | ||
| ... | ||
|
|
||
| deno_core = { path = "../core" } |
There was a problem hiding this comment.
This is not how you'd usually add deno_core.
There was a problem hiding this comment.
yep, outside the deno project we rely on the Rust community’s crate registry! Change done
test_plugin/README.md
Outdated
|
|
||
| ```js | ||
| // in test.js | ||
| const rid = Deno.openPlugin(<path to *.dylib>); |
There was a problem hiding this comment.
The lib is not always a.dylib.
Windows: .dll
Linux: .so
MacOS: .dylib
test_plugin/README.md
Outdated
| └── test.js | ||
| ``` | ||
|
|
||
| It is a rust repo. |
|
|
||
| ```rust | ||
| // in lib.rs | ||
| fn op_test_sync( |
There was a problem hiding this comment.
Should also cover op_test_async
There was a problem hiding this comment.
async ops are managed the same way!
| #[no_mangle] | ||
| pub fn deno_plugin_init(interface: &mut dyn Interface) { | ||
| interface.register_op("testSync", op_test_sync); | ||
| ... |
| #### 4- build your lib with cargo : `cargo build -p <name of the crate>` | ||
|
|
||
| ```shell | ||
| $ cargo build -p test_plugin --release |
There was a problem hiding this comment.
just cargo build --release should be enough
I do not agree! test_plugin is a good start to check... If you have other ideas, please suggest something! |
|
I think it's a really good idea to actually explain how to create a simple test plugin, what it uses, how it works, what these methods do etc. Then a user can use this information to be confident enough to build whatever they want |
Solving #7030