Feature / pull request: API-based indexes

[simian-loco]

Background

I use schemas for role-based segmentation of what is available to whom (via postgrest). This means I have apis like the following:

• GET api.example.com/public/features
• GET api.example.com/users/features

In this example there are two of the same resource "features" on separate schemas pointing to different views. One uses the "users.features" api/schema and the other uses "public.features" api/schema.

Issue

The generateIndexFile generator currently outputs conflicting results for my situation. There are two separate "features" exports) via the generated ${outputPath}/index.ts index file.

Solution

PR: Fix for "duplicate identifier" via generateIndexFile hook for multiple schemas #558

The proposed solution is to use pretty much the same logic as the global index.ts file; but building up the schema-based index.ts files when generating the output, if schemas are being used.

This is currently an "all or nothing" result for someone using schemas. There is either a "global" outputPath index or schema based index files. I would argue that this is prudent given overlapping view names are in-spec for postgresql.

All kanel package tests are passing for what it's worth.

Potential Enhancements

• Currently the solution uses the declaration item path for determining if the declaration is a part of a larger schema, piggy backing on earlier schema-related logic. Perhaps the solution here could look and learn from that earlier logic to determine a more reliable and stable way of determining the schema output path
• The solution could probably be more performant; but that's usually the case when time constraints are involved

Feel free to edit / feedback / merge / etc.

Thanks for the library!

[simian-loco]

Does config.schemas reference only the schemas added to .kanelrc.js? Are other schemas (e.g. private schemas or extension schemas) not included within .kanelrc.js missing from this method of resolution?
resolveType.ts#L162-L201

I am not quite sure where the config.schemas is being produced. Could you point me the way?

Some extra context: the types are resolving, but I am manually setting siNullable and isOptional to true via the config. It seems that the resolution method cannot drill down enough to determine this automatically. This might be because I am deleting the source property via my patch-1 update (deleted in order to resolve the types for the properties).

This actually is probably better discussed here.