Вот предыстория: мы разрабатываем AWS CDK модулей, используя Typescript (к сожалению, я не очень разбираюсь в TS).
Например, будет модуль для представления приложения на основе контейнера, которое разработчики могут использовать для предоставления своих услуг. Очень высокий уровень, «определение» каждого приложения будет выглядеть примерно так (очень высокий уровень):
import {containerApp} from 'CompanyContainerApp'
const environment = callSomeMethodToFindEnv() // for example, 'prod'
config = import('/prod')
const myApp = new containerApp(`myapp-${environment}`, config)
Так что проблема здесь в том, что «prod» и «dev» представляют разные значения конфигурации, которые нуждаются быть отправленным конструктору containerApp
. Конечно, я мог бы go с простыми json файлами и анализировать их, но эти конфиги могут быть сложными, и их наличие в типе значительно упростит express, какие атрибуты конфигурации требуются, которые являются необязательными и т. Д. c.
Прямо сейчас это мой код:
// cat index.ts
import {Config} from './configdefinition'
export function hello(word: string = world): string {
const envName = 'prod'
const config: Config = import(`./${envName}`)
return `Hello2 ${world}! `
}
hello()
// cat configdefinition.ts
export class Config {
// props with defaults
readonly numberOfLegs: number = 8
constructor(
// required props
readonly name: string,
readonly lastname?: string
) {}
}
// cat prod.ts
import {Config} from './configdefinition'
const config = new Config(
'prodman',
'wakka'
)
export default config
Typescript жалуется, что 'config' является "обещанием", а не экземпляром класса Config
. Я знаю, что это открытый вопрос, но я думаю, что я пытаюсь выяснить, возможно ли это вообще, или я должен просто придерживаться старой школы json для своих конфигов (что было бы позором, но это не убьет нас).
В настоящее время ts жалуется, что мой config
const действительно обещание, а не экземпляр класса Confg
- похоже, что он использует функцию import
Я повергну меня в темную пропасть необходимости иметь дело с обещаниями и т. д. c, и я надеялся избежать этого.
Так что я думаю, что это немного открытый вопрос, но подытожим: 1 Должен ли я просто отказаться от использования json конфигов вместо 2. Если нет, каков будет правильный способ динамического импорта другого экземпляра класса, сохраняя при этом «сильные» типы? (например, чтобы знать, что объект config
является экземпляром Config
)
Любые указатели высоко ценятся, я довольно новичок в Typescript.
UPDATE : Ответ отправлен мне прямо, я сейчас изучаю, используя обещания. Это то, что я до сих пор придумал:
// cat configdefinition
export class Config {
// props with defaults
readonly numberOfLegs: number = 8
constructor(
// required props
readonly name: string,
readonly lastname?: string
) {}
}
// cat prod.ts
import {Config} from './configdefinition'
export const config: Config = new Config('Bobba', 'Fett')
//cat index.ts
import {Config} from './configdefinition'
export function doSomeStuff(config: any) {
// @ts-ignore
const thisConfig: Config = config.config
console.log(thisConfig.lastname)
}
export function hello() {
const envName = 'prod'
const configImport: Promise<Config> = import(`./${envName}`)
configImport.then(
result => doSomeStuff(result)
)
}
hello()
Так что это работает, мне пришлось добавить ts-ignore для машинописного «force» для динамического извлечения атрибута config
dynamici c Импортировать. Я подозреваю, что есть способы сделать это, которые не требуют такого рода нарушения правил, но в настоящее время я доволен этим. Надеюсь, это поможет кому-то в будущем.