Smart items, custom components and systems

[cazala]

This conversation has been moved over here: https://github.com/decentraland/sdk/issues/933

Background

Items used to be only a GLB + Transform, but that would only allow us to create static scenes. In the legacy Builder we had the concept of "smart items" that had some interactivity baked in and enabled users to create some flows and simple game logic.

Now items can have more components than only GltfContainer, like Triggers and Actions, but when using those, they need specialized systems to be running, and custom components to be added to the engine.

The original plan to support this was the following:

• Each items would list its dependencies (ie @dcl/asset-packs@1.0.0)
• When an item is dropped into the scene, if it has dependencies and they are not already tracked in the project, they are added (ie. added to the package.json), and the necessary components are created with their values (exposed by the item data.json)
• Once the dependencies are installed/downloaded (ie. from an npm registry or cdn like unpkg), we need to:
  • re-create the bin/index.js on the web editor, on the vscode editor we would need to add the imports to the entrypoint
  • in runtime, we need to add the new components to the @dcl/inspector's engine

Some of the problems found:

• The packages would need to export a static representation of the components instead of the actual component itself (created with engine.defineComponent) because the we need to run this not only on the deployed scene, but also on the @dcl/inspector engine itself, and also we need to namespace the name of the component with the package name and version otherwise they could clash
• We would need to compile the javascript file on the browser, we tried using @swc/wasm but we could not manage to make it work with our current build system in esbuild.
• Even if we would have made the compiler to work, we still couldn't figure out a way to make it also compile dependencies of the packages themself, we wanted to be able to use @dcl-sdk/utils.
• How should we handle two items with the same dependency on different versions?

What we ended up doing:

• We created a single package that contains all the systems for the items to work in this repo @dcl/asset-packs. It can have its own dependencies like @dcl-sdk/utils.
• The CI compiles the bin/index.js file and publishes in the npm package along with the components needed by the @dcl/inspector engine
• The @dcl/inspector installs the @dcl/asset-packs dependency and it uses those components on its own engine, and it publishes the bin/index.js from that dependency along with the other static assets in its own @dcl/inspector npm package
• Whover uses the @dcl/inspector (ie. the Builder) can pass a binIndexJsUrl param that tells the inspector from where to get the bin/index.js, since the builder serves the static assets from the @dcl/inspector (html, css, etc) it also serves the bin/index.js, so it passes the public url of that bin/index.js as the binIndexJsUrl.
• In the future, if we wanted to generate the bin/index.js elsewhere (ie. a server that compiles the js) we could simply change this url to the service that will return the compiled js.
• We can add new smart items to the asset-packs repo using the available components without having to release a new @dcl/inspector but if we want to add new functionality or new components/systems, we need to add them to the @dcl/asset-packs repo, and then upgrade the depdency (and might need to create UI components for them) in ther @dcl/inspector.

[menduz]

Important details about rationale behind engine.defineComponent and how this feature was planned to work around it in the ADR-165 @cazala

[cazala]

This conversation has been moved over here: https://github.com/decentraland/sdk/issues/933