trygve-lie
commented
2 years ago It would be awesome to have some metrics and UI tools for Eik so great suggestion.
a POC for this https://github.com/eik-lib/core/pull/341 which would make it possible to hook in to shared lib and import map changes and create slack/chat messages when libraries and import maps are updated or published.
I think the plugin API would be ideal for integrating a bot which can be used to send messages to slack etc as you say.
Perhaps my thinking here is wrong and pkg and npm do make the most sense in which case
The two namespaces npm and pkg is there for one reason: to avoid name collision. Since we are not using NPM as a backend but we want to republish NPM packages plus we see that there is packages (mostly app code but also library code) we want to put on a CDN but not reserve a namespace for in NPM we need two namespaces so ex the name of a internal project we don't want to publish to NPM does not collide with a package with the same name on NPM.
So, the npm namespace has nothing to do with a package being what we call a shared library in FINN. I think you might think a little bit too much how we structure shared libs in FINN for this.
I am not 100% sure we should start grouping the files into how we base an organization structure. I think we should keep packages and maps in clean file structure and if we need a way to group these into some organization structure that should be a separate thingy which just refer to the files in the file structure.
But if we think a bit API here; currently there is no listing for this in the Eik server:
GET https://assets.finn.no/map/
GET https://assets.finn.no/pkg/
GET https://assets.finn.no/npm/All these return a 404 and there is no way to list all maps, npm or pkg packages in Eik.
What if ex https://assets.finn.no/map/ returned a list of all maps. Something like:
[
{ "name": "react" },
{ "name": "vue" },
]This can be used for listing all maps in a UI (*).
Then I think that the listing for a map might be missing some key data. What if:
GET https://assets.finn.no/map/react/returned something like so:
{
"versions": [
[18, { "alias": "18.0.1", "latest": "18.0.2", "deprecated": false }],
[17, { "alias": "17.1.1", "latest": "17.1.1", "deprecated": false }],
[16, { "alias": "16.2.4", "latest": "16.2.4", "deprecated": true }],
],
}This would make it possible with one request to a map to see what versions is flagged as active and which version an alias points too and what it the latest version published.
Then we might would like a separate API for maybe grouping a set of maps we want stats on we can use to list a given grouping of stats.
Background
I have been implementing a dashboard for Finn.no that helps give a better oversight into organisation wide shared dependencies, import maps and their aliases. I was able to achieve quite a lot, but there are some key issues:
Additionally, the type of functionality I have created would be a welcome addition to Eik itself to avoid the need for different organisations to implement their own dashboards but what I have currently is very coupled to Finn due to the need to keep lists of shared libs and import maps manually.
Dashboarding APIs
It would significantly improve the ability to create dashboards if we had some additional Eik APIs and tracked some additional state. I've outlined what I think could done.
Plugin API
@trygve-lie created a POC for this here which would make it possible to hook in to shared lib and import map changes and create slack/chat messages when libraries and import maps are updated or published.
Organisation import map endpoint
An endpoint for organisation wide import maps would remove the need to keep a list of which import maps the org is using.
eg.
https://assets.finn.no/maps/finnWe would need to start tracking each import map created against an org.
Organisation shared lib endpoint
An endpoint for organisation wide shared libraries would remove the need to keep a list of which shared libraries the org is using.
eg.
https://assets.finn.no/npm/finnThis raises the question, should the namespace
npmactually be used more generically and actually mean "shared libraries"? Since it is only a namespace, are we coupling it too closely to NPM with the current name?We currently have shared libs that are published to npm and also some that are published to pkg. A better distinction in a way would be "apps" and "libs". Perhaps my thinking here is wrong and pkg and npm do make the most sense in which case, we will still need a way to mark either one as a "shared lib" and keep track of this.
Shared lib and import map deprecations
For both shared libs and import maps for an org, it would be nice to be able to mark them as deprecated and then filter out deprecations when querying. This would also allow us to more easily phase out import maps and libs over time.