Support for custom systems

[kgpax]

What does this PR do

• Changes the definition of a system so that icons are defined as base64 data rather than a file path. This is so that:
  • We have no external dependencies for systems (i.e., no additional files)
  • We remove that new URL('filePath.svg', import.meta.url); approach which parcel seemed to love but all other tooling and build steps despised.
• Updates the build process to build an integration bundle which allows other apps to create their own systems to be registered with the @envyjs/webui viewer.
• Exports the @envyjs/webui viewer app component to allow thew viewer to be hosted in another application for customisation.
• Updated the npx @envyjs/webui command to support a --noUi flag, which would prevent it from starting the default viewer application, and only start the collector web socket server.

Hear me out...

I was hoping to find a way to be able to have custom systems be something that could be registered against the default viewer application running on http://localhost:9998/ when you run npx @envyjs/webui.

However, this has proven to be quite troublesome to implement. The main issues are:

• How do we inject code from one application into another application that is already running?
• How do we ensure that our injection target is the actual viewer web application, and not the node process acting as a web server for it?

That latter one proved to be the most challenging aspect. The only interface we have with @envyjs/webui is with the node processes which start the collector and the viewer web server. If we were able to register custom systems with the node process that starts the viewer web server, then this would still not be something that the actual running web application will see.

I remain fairly confident that this is something that can be solved, but in the interest of delivering something of value and allowing for iteration, this PR takes a different initial tact.

How to customise the Envy web viewer

I've added some initial documentation to docs/customizing.md, but the summarise, in your client application which will send traces, you would:

• Create a new component which uses the <EnvyViewer /> component exported from @envyjs/webui.
• Use this component, and pass it an array of systems which you have created in your application.
• Run the npx @envyjs/webui command with the --noUi flag
• Run your own component which hosts the <EnvyViewer /> component instead.

Example

I've updated the examples/apollo-client application to demonstrate this:

• Added new /src/viewer.html and src/viewer.js files to be used as entry points for a new parcel-served application
• Created a couple of new systems:
  • ./src/systems/CatFacts.tsx
  • ./src/systems/CocktailDb.tsx
• Registered these systems with the <EnvyViewer /> usage in ./src/viewer.js

This means that we now recognise requests to these two systems:

These systems also become something that you can filter by:

Show me!

• Run yarn example:apollo from the root of the repo.
• Open http://localhost:4002 in your browser for the custom hosted Envy viewer
• Open http://localhost:4001 in another browser tab for the application
• Verify that the traces for the cat facts and cocktail requests reflect the systems

[changeset-bot]

🦋 Changeset detected

Latest commit: 4a1a936

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@envyjs/webui	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[carbonrobot]

We should consider syncing the esm build dep versions, so we don't carry multipl

[kgpax]

This is just the result of yarn add -D esbuild. How should this be done? Would we need to add a "resolutions" section to the main package.json to force a specific version where other dependencies have this as a subdependency?

[kgpax]

Looks like the "vite" dependency in "example-express-client" is where the other one is coming from: https://github.com/vitejs/vite/blob/v4.4.9/packages/vite/package.json#L70

[kgpax]

@carbonrobot is this something that we need to do? Not sure whether it's worth forcing the vite dependency in one of our examples to use a specific esbuild version. The main import we have is the 0.19.x one which we specify, the 0.18.x sits in the node_modules/vite/node_modules directory, somewhat out of harms way.