Custom Directus Extension Placement

[thanaParis]

In order to facilitate showing the live ChargingStations connection status on Directus, I've needed to create a few custom extensions (see the feature/evse-connection-status branch). Directus custom extensions require their own package structure because they need to be built using a particular package.json. Right now, my plan is to bundle the custom extensions into a structure like this:
Server/data/directus/extensions/directus-extension-citrineos-charging-stations/package.json
We can run npm commands from that directory to install dependencies and build the code. By committing the dist/ folder, you won't need to rebuild the code unless you're making changes to it.
This works, but is awkward.
There's a few other options--

1. We could put the code in its own package in citrineos-core, then use docker compose volumes to mount it to Server and Swarm's Directus images.
2. We could put the code into its own git repository, but make it a git submodule of citrineos-core, which would effectively leave the code in the Server/data/directus/extensions folder.
3. We could do either of the above (own package in citrineos-core or own git repository) then publish it to the npm registry and add it to Server and Swarm's Directus images via Dockerfile.

What are your thoughts?

[elliot-sabitov]

"Right now, my plan is to bundle the custom extensions into a structure like this:
Server/data/directus/extensions/directus-extension-citrineos-charging-stations/package.json" - I would be a bit careful here because it seems that putting extensions into Server would mix the custom Directus extensions with the Citrine code. In addition, the Server/data/ directory contains the postgres DB content that is generated automatically when you run the docker compose as it creates the postgres container. I would find it difficult to make sense of putting the Directus extensions code into the data folder.

I would suggest keeping the extensions in a separate directory in the root. That way, we can build the extensions and deploy them, but also we would be able to mount them locally to be able to have breakpoints in the extensions and speed up custom extension development locally. In the Directus docker compose, we can make adjustments to load the extensions into the Directus docker image while also being able to expose the debugger port.

We can consider putting the custom extensions to a separate repo (or sub module) or NPM, but I don't see that as being absolutely necessary since these extensions really do apply to the Citrine Directus instance which would not really be used outside of Citrine so keeping it in same repo makes sense to me.

[lydiazcheng]

I would vote for own package in citrineos-core. No preference on using docker compose volumes or publishing it to the npm registry.

[thanaParis]

Draft PR opened with extension in root: citrineos/citrineos-core#64

[ChrisWeissmann]

I for sure see the point of having it in citrine-core. But I think a repo under the citrine project that gets pulled in for server/swarm as a submodule would be better. Directus isn't really part of our solution, it's a UI to show our solution, it offers lots of nice features to build nice complex back office things. But that's all on top of citrine, not really part of it.
Does it work with having it in NPM? If yes, it would probably be nice to have it packaged and ready to use.

If we do keep it in the core repo, we should have a parent directory like directus-extentions to be flexible for additional extensions. I don't think having a bunch of extensions on the top level would be very nice.

[thanaParis]

If we do keep it in the core repo, we should have a parent directory like directus-extentions to be flexible for additional extensions. I don't think having a bunch of extensions on the top level would be very nice.

This is a good point. What sort of naming/folder structure would make sense? directus-extension-charging-stations-bundle is clunky...

We could make it just "ChargingStationsUI"? Or, 'DirectusExtensions' and have the bundle be a subfolder as @ChrisWeissmann suggested?

[ghost]

+1 to making a folder dedicated to Directus extensions called something like DirectusExtensions and have the bundle be a subfolder 👍 If we want to not necessarily reference Directus in the name for some reason, maybe UIExtensions could also work? But either way keeping all that stuff in its own folder seems cleaner😄

[thanaParis]

DirectusExtensions/ now contains charging-stations-bundle.

I have a new question, since we've made this change--does it continue to make sense to bundle the charging-stations related extensions? Or should they all be separate now?

@elliot-sabitov you were implying there's additional overhead to keeping it as a bundle. would you prefer they be broken out:
DirectusExtensions/display-true-count
DirectusExtensions/endpoint-update-station-status
DirectusExtensions/hook-on-create-station

[elliot-sabitov]

although the naming is flexible, I think directus-extensions may be more fitting. In terms of how you choose to structure your extensions inside the directus-extensions folder I think can be flexible. For me, the requirement would be that there is a parent folder and that there is a solid approach to sharing code between extensions. Most extensions will need to do common things like make API requests or talk to DB and we need to have a way established to share that code. Bundles are a good approach to accomplishing this because if you just have a .ts files in a /shared folder somewhere that is being pulled into multiple directus extensions, it actually still ends up packaging them multiple times and say if you followed the singleton pattern, you would still have multiple isntances because there would actually be multiple instances of the class defined. Creating bundles allows for a good structure to share the code. I would not create a separate bundle for each feature set, but perhaps just have one bundle with the various extensions