Exporting CDK classes/types medplum #support

Exporting CDK classes/types

codingtom

09/20/2023, 10:41 PM

I'm attempting to bootstrap a self-hosted Medplum instance in AWS. We currently provision our infrastructure via Pulumi, which in theory has support for managing CDK stacks. This would be straightforward for me to implement if the

@medplum/cdk

package exported a few more things - e.g. the

BackEnd

FrontEnd

, etc classes. Heck, even the top-level

MedplumStack

would be useful. Would folks be opposed to adding these as exports from the package? This would allow myself and other groups to programmatically use the CDK configuration. It'd be a few extra lines of code in

index.ts

to re-export from the relevant source files, but the downside is that it increases the package's "API surface", which may be undesirable, I'm not sure. I've tried importing the TS files from the package directly, which sort of works, but I think our TS config is more strict than yours and it complains about type errors - even with

skipLibCheck

etc turned on. Alternatively, I can recreate the whole stack in native Pulumi configuration, but I kind of like being able to keep our config in sync with current Medplum best practices over time. https://www.pulumi.com/ https://github.com/pulumi/pulumi-cdk https://github.com/medplum/medplum/blob/main/packages/cdk/src/index.ts#L10

cody

09/20/2023, 10:58 PM

1. No objection, i think exporting the CDK types is a great idea. 2. I'm curious which TS rules are failing? We try to maximize strictness settings, so if there's something we're not correctly satisfying, I'd love to fix that too.

cody

09/20/2023, 11:19 PM

Tracking ticket - https://github.com/medplum/medplum/issues/2898 - we'll get this out today

codingtom

09/20/2023, 11:51 PM

Awesome, thanks!

codingtom

09/20/2023, 11:54 PM

The primary typecheck failures were around inferred types of a

let

statement, e.g.:

Copy code

let record = undefined;
    if (!config.skipDns) {
      // ...

      // TS Error: Type 'ARecord' is not assignable to type 'undefined'.ts(2322)
      record = new route53.ARecord(this, "LoadBalancerAliasRecord", {
        // ...
      });
    }

codingtom

09/20/2023, 11:54 PM

There were 4 or 5 similar cases

codingtom

09/20/2023, 11:55 PM

We also use

eslint@typescript-eslint/consistent-type-imports

which complains about

import { MedplumInfraConfig } from "@medplum/core";

- but that's just a style preference really

cody

09/21/2023, 7:00 PM

Got it. Thanks @codingtom ! I might just go ahead and enable those eslint rules, because they look smart. We'll get this out soon. thanks

156 Views

Previous Next