Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/denoland/deno_lint/issues/175 below:

plugin support · Issue #175 · denoland/deno_lint · GitHub

It would be great if deno_lint had support for plugins that can add rules. Here are my thoughts:

Constraints:

• Plugins should be written in Rust and use the same infrastructure as the rules that are part of this repository.
• Plugins should be loaded at runtime, and should not have to be available at compile time. This means they need to be dynamically executed.
• Plugins should not have to re-parse the source code.
• Plugins should be sandboxed and safe - they should not be able to access the system directly.

Possible solution:
Most likely the best solution that satisfies these constraints is WebAssembly. You can write your rules in Rust, and then compile them to WebAssembly that deno_lint could load and run. WebAssembly is also safe because it is sandboxed and only gets access to resources that deno_lint exposes to it. Here is how I imagine this would work:

1. deno_lint should initialise all plugins at startup, by creating a WebAssembly VM for each plugin.
2. deno_lint parses the source code into a swc AST. This ASTs raw memory is stored in a shared memory area with the WebAssembly plugin.
3. deno_lint calls a function in WebAssembly to kick off code checking in the plugin. It can now do its analysis and create diagnostics. These diagnostics are stored in a separate section of shared memory between the plugin and deno_lint.
4. deno_lint extracts these diagnostics and augments them with information about plugin origin and returns them to the user.

This approach would allow you to start multiple instances of the same plugin easily, to paralelnize code analysis for large modules.
There are definitely some issues with this. The biggest one I can see right now is how to pass the AST between plugin and deno_lint. If we only support rust, we might be able to pass the raw backing of the object, but I don't know if this is feasible and how likely it is to break (probably very). Another solution would be to serialise to JSON or protobuf and then deserialise on the plugin side. This is definitely possible, but requires a lot of careful translation of the swc structs into JSON. This might be very complicated and time intensive, and would probably not be great for performance. The third solution would be to have the plugin do the parsing of code itself - this would also slow down the process significantly though.

Prior art:
dprint also makes use of WebAssembly for its plugin system. To the end user looks like this: https://dprint.dev/plugin-dev/ (very clean)

ardyfeb, andriyor, andreolvr, magurotuna, newtack and 16 moredandvcoderaiser, Roosteridk and randallbMqxx and Macil

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4