Отображение путей машинописного текста не переводится в приложении узла

В настоящее время используется машинописный текст в приложении node.js. Я скомпилировал свое приложение и использую сопоставление путей машинописного текста. функция.

Вместо этого 'api/*' следует искать в корневой папке. Использование в разработке:

nodemon --watch src -e ts,tsx --exec ts-node -r tsconfig-paths/register --disableWarnings ./src/index.ts

tsconfig-paths/register позволяет правильно перевести требование, и ts-node будет правильно выполнять/запускать приложение. Теперь проблема возникает, когда я перехожу к производству. В прошлом в рабочей среде я просто запускал tsc в папке и перемещал содержимое outDir (dist/) в /app в моем образе докера и запускал node /app/index.js. Это работало, пока я не начал использовать функцию сопоставления путей машинописного текста. Теперь я просто получаю сообщение об ошибке:

Ошибка: не удается найти модуль «api/module/path/here»

Из этого комментария github имена модулей явно не сопоставляются с скомпилированными выводами. JavaScript.

Мой файл tsconfig.json:

{
    "compilerOptions": {
      "target": "es2015",
      "module": "commonjs",
      "moduleResolution": "node",
      "allowSyntheticDefaultImports": true,
      "jsx": "react",
      "allowJs": true,
      "alwaysStrict": true,
      "sourceMap": true,
      "forceConsistentCasingInFileNames": true,
      "noFallthroughCasesInSwitch": true,
      "noImplicitReturns": true,
      "noUnusedLocals": true,
      "noUnusedParameters": true,
      "noImplicitAny": false,
      "noImplicitThis": false,
      "strictNullChecks": false,
      "experimentalDecorators": true,
      "emitDecoratorMetadata": true,
      "lib": ["es2017", "dom"],
      "baseUrl": "src",
      "outDir": "dist",
      "types": [
        "node"
      ],
      "paths": {
        "universal/*": ["../../universal/*"],
        "api/*": ["*"],
        "*": ["node_modules/*"]
      },
      "typeRoots": [
        "./node_modules/@types",
        "./src/types"
      ]
    },
    "include": [
      "src/**/*"
    ]
}

Каков рекомендуемый подход к использованию относительного сопоставления путей в среде node.js? Если машинописный текст выполняет разрешение, почему бы ему не переписать операторы запроса? Кажется глупым использовать еще один шаг, такой как babel или webpack, только для того, чтобы добавить функциональность, которую typescript предоставляет с разрешением модуля.

РЕДАКТИРОВАТЬ: после дополнительных копаний я обнаружил, что могу использовать -r tsconfig-paths/register в своей среде узла (мне просто нужно скопировать в файл tsconfig.json). Я могу переключить свою точку входа в докере на:

ENTRYPOINT [ "node", "-r", "tsconfig-paths/register", "index.js" ]

Проблема в том, что теперь мне нужно изменить мой tsconfig.json baseUrl, так как каталог src/ не существует. Кроме того, я заметил, что разрешение не работает для модуля «util» (очевидно, он использует util в моей папке node_modules вместо библиотеки util node.js), что вызывает сбой моего приложения.


person Goodbye StackExchange    schedule 20.12.2017    source источник


Ответы (1)


В соответствии с предоставленным вами источником вы можете использовать (например, разрешить последний путь КАК первый путь):

"rootDirs": [
      "src/api/module/path/here",
      "api/module/path/here"
    ]

Проблема в том, что теперь мне нужно изменить мой baseUrl tsconfig.json, так как каталог src/ не существует.

функция сопоставления путей машинописного текста гласит:

Гибкость rootDirs не ограничивается указанием списка физических исходных каталогов, которые логически объединены. Предоставленный массив может включать любое количество случайных, произвольных имен каталогов, независимо от того, существуют они или нет. Это позволяет компилятору захватывать сложные функции связывания и времени выполнения, такие как условное включение и подключаемые модули загрузчика проекта, безопасным для типов способом.

Кроме того, вы пробовали разрешение модуля трассировки: tsc --traceResolution

person Gillsoft AB    schedule 29.12.2017
comment
ts-узел правильно компилируется и работает с текущей конфигурацией. - person Goodbye StackExchange; 29.12.2017