Skip to content

WASM Plugin / extension system #104

@thedodd

Description

@thedodd

Abstract

Given that there will always be new features that folks want to add to Trunk, but adding too much to Trunk core would cause a fair amount of bloat, we will eventually want to expose a plugin system. The following is a non-exhaustive list of what we would like to see from the plugin system (please comment below if you would like to add or remove items):

  • Ability for users to create their own plugins which will be loaded by the Trunk CLI and will be called as part of the standard Trunk build pipeline.
  • Ability for plugins to declare the asset types which they will operate on.
    • In the source HTML, this should be declared as something like <link data-trunk data-plugin rel="my-plugin-type" any-other-attrs="will be passed to plugin"/> (this needs further discussion).
    • Trunk should see that the link is a plugin, and then will call any registered plugin which matches the rel="my-plugin-type".

The Trunk team should build and maintain a trunk-plugin library which exposes common types used by Trunk itself, and which plugins should use to facilitate communication between Trunk and the plugin. Big shoutout to @lukechu10 for pointing out that WASM is perfect for this.

  • This library will expose types needed to declare the Trunk ABI version which the plugin is using. This will allow us to safely evolve the plugin ABI without breaking old plugins.
  • Which runtime should we use? Personally I like wasmer a lot. I've used it a bit and it is pretty solid. A lot of other folks in the WASM community outside of the Rust context are using it as well.
  • What should the ABI look like which the WASM plugin modules need to expose?
  • What are the ABI capabilities which Trunk should expose to plugins? This is gonna be a big item for discussion.

We need to gather some feedback.

  • What do folks want to do with these plugins? This is nothing new. Many of the build/bundle tools in the JS ecosystem have plugin systems.
  • What sort of data will the plugins need?
  • What should our algorithm be for plugin discovery?

We will also want to discuss what Trunk itself should do in order to aid plugin authors in compiling, optimizing and publishing their WASM-plugins.

There is a lot to discuss here.

Metadata

Metadata

Assignees

No one assigned

    Labels

    discussionThis item needs some discussionneeds designThis item needs design work

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions