Error ts18002 the files list in config file tsconfig json is empty

Я также столкнулся с этой проблемой при запуске тестов на эльзасский язык после обновления до ts-node v7. Я обнаружил, что могу решить проблему, указав флаг --files CLI.

Проблема, по-видимому, связана с тем, что тестовая среда require s каждый .test.ts файл по очереди, и каждый вызов require похоже, компилирует каждый модуль в дереве зависимостей этого файла. с нуля. Указание --files возвращает к старому поведению загрузки всех файлов при запуске (и предположительно кеширует их в памяти).

@blakeembrey: это похоже на правдоподобный диагноз, и можете ли вы найти лучшее решение?

Вы пробовали режим --transpile-only ?

Сегодня я столкнулся с подобной проблемой. После обновления ts-node с 7.0.1 до 8.0.1 мой набор тестов мокко стал очень медленным (32 секунды против 4). Добавление TS_NODE_TRANSPILE_ONLY = true решило мою проблему. Спасибо @cspotcode

--transpile-only для меня значительно ускоряет работу. Однако я не хочу терять проверку типов!

Перепробовал все предложенные решения. files: true значительно ускоряет выполнение! Отключение проверки типов также ускорило работу. Мне просто пришлось отключить typeCheck и включить transpileOnly ( typeCheck: false, transpileOnly: true ). Это достаточно хороший обходной путь, но кажется, что поведение по умолчанию все еще странное.

Это интересно, files: false определенно предназначен для того, чтобы делать вещи быстрее, чем медленнее. Есть ли у кого-нибудь достаточно большой проект, который работает медленно, и он хочет либо 1. выяснить, является ли причина, по которой упоминается

В идеале files: false загружает один файл и выводит пауков, поэтому возможно, что это небольшая проблема с производительностью. Также возможно, что предыдущая версия сильно ударила по кешу, если вы обновились с v7 до v8 (v8 удалил кеш из-за проблем с типом). Мы также могли бы исследовать добавление кэширования обратно, но оно должно быть намного умнее, чем предыдущая версия, чтобы разрешать изменения переходных типов.

Я тоже столкнулся с этой проблемой после обновления с 7.0.1 до 8.0.1.

Из того, что я могу сказать, когда files: false файл tsconfig.json изменяется в памяти для удаления атрибутов files и includes .

https://github.com/TypeStrong/ts-node/blob/544851ee58af539908c682c547e05508e3dfb731/src/index.ts#L484

Кажется, это создает недопустимую конфигурацию (при использовании TypeScript 3.2.4):

error TS18002: The 'files' list in config file 'tsconfig.json' is empty.

Однако полное удаление атрибутов files и includes , похоже, решает проблему.

Если кто-нибудь может дать мне временный доступ к медленному репо, дайте мне знать! Я могу быстро разобраться в проблеме и с радостью подпишу любое NDA и т. Д., Которое вам нужно. Если нет, могу ли я получить представление о людях tsconfig.json которые работают медленно — вы полагаетесь на files , include , exclude , rootDir или другое для компиляции с TypeScript?

Попробуем с реакциями:

• ❤️ files
• 🚀 include
• 👀 exclude
• 😕 rootDir
• 🎉 Другое

8.0.2 для меня ничего не изменило. Тот факт, что он добавляет files: [] к tsconfig.json прежнему убивает производительность.

К сожалению, я не могу поделиться нашим проектом, но вот наш tsconfig.json :

{
    "compileOnSave": true,
    "compilerOptions": {
        "emitDecoratorMetadata": true,
        "experimentalDecorators": true,
        "forceConsistentCasingInFileNames": true,
        "lib": [
            "es2017"
        ],
        "module": "commonjs",
        "moduleResolution": "node",
        "newLine": "LF",
        "noEmitOnError": true,
        "noImplicitReturns": true,
        "noUnusedLocals": true,
        "noUnusedParameters": false,
        "outDir": "dist",
        "removeComments": true,
        "rootDir": ".",
        "sourceMap": true,
        "strict": true,
        "strictFunctionTypes": false,
        "suppressImplicitAnyIndexErrors": true,
        "target": "es6"
    }
}

@garethflowers Используете ли вы mocha или что-то еще, что объясняет в https://github.com/TypeStrong/ts-node/issues/754#issuecomment -456788194?

В качестве альтернативы, можете ли вы попробовать заполнить files = ['one.ts file here'] чтобы оно было действительным, но все же переопределенным, и сообщить мне, если это что-то изменит?

@blakeembrey Я сделал минимальное воспроизведение на https://github.com/davidgruar/tsnode-perf-repro — пожалуйста, проверьте это и сыграйте. Загрузка всего трех тестовых файлов с довольно небольшим количеством зависимостей занимает больше секунды, и чем больше импортов вы добавите, тем больше времени это займет.

Когда вы рассчитываете время всей программы, это не похоже на огромные накладные расходы, вместо того, чтобы просто требовать:

Однако есть разница, поэтому для тестирования может быть наиболее целесообразным включить --files тогда как при запуске приложения этого не происходит — есть только один ввод, и TypeScript все равно предварительно обрабатывает все. Я рассмотрю это подробнее, потому что разница очевидна, и было бы неплохо уменьшить количество динамических файлов.

Ок, прекрасно. Похоже, что TypeScript делает в 4 раза больше запросов к файловой системе, когда files: false . Изучите, есть ли какие-то проблемы с тем, как здесь работает TypeScript, и как это можно улучшить.

Я обнаружил несколько настроек, которые способствуют медленному времени компиляции, я уверен, что проблема связана с настройками, которые удаляют настройку по умолчанию ignore: node_modules. IE: allowJs. Другие, которые также могут (просто из моей памяти предположить / проверить), это removeComments, emitDecoratorMetadata и некоторые другие. Я также заметил, что если вы используете glob без файла ext, например include: src / / * вместо src / /*.ts, это может вызвать замедление, idk, если его chokadir просматривает файлы шрифтов, которые могут быть там или что-то в этом роде. Однако использование isolatedModules — верный способ ускорить процесс.

@ jeremy-coleman Извините, я не совсем понял. Не могли бы вы сообщить мне, кому вы / что здесь отвечаете?

Изменить: я не думаю, что какие-либо из них связаны с основной причиной проблем, упомянутых в этом потоке, вот и все.

@blakeembrey Привет, я тоже создал пример: https://github.com/lukashavrlant/ts-node-perf Но я думаю, он похож на предыдущий пример. В основном компиляция файлов TS в файлы JS, а затем запуск тестов мокко с использованием сгенерированных файлов JS выполняется быстрее, чем использование напрямую ts-node. См. Readme для получения более подробной информации. Чем больше импортных файлов я использую, тем медленнее он работает. В качестве примера я использовал нулевой импорт в тестовых файлах.

К сожалению, это определенно так. Я не уверен на 100%, почему в языковых услугах это так дорого. Похоже, что изменение rootFiles приводит к «устареванию проекта», и начинается повторное разрешение всех типов и обход node_modules . Это очень плохо в случае тестовой загрузки — мне нужно найти способ использовать ранее кэшированные разрешения, а не пытаться повторно разрешить все при изменении корневых файлов. cc @ TypeStrong / typescript-team @weswigham на случай, если я что-то не так делаю.

@sheetalkamat , знаете ли вы, что нужно сделать, чтобы разработчики API могли сохранять кеш разрешения во всех сборках?

Когда хост не имеет resolveModuleName, он создает кеш для каждой программы. Таким образом, всякий раз, когда программа изменяется, создается новый кеш разрешения. (Обратите внимание, что это отличается от внутреннего кеша разрешения, который используют tsc и tsserver, который осведомлен о том, какие файлы были изменены и, следовательно, какие разрешения следует аннулировать) Я не думаю, что ModuleResolutionCache который есть у компилятора, оборудован для обработки изменения и, следовательно, его для каждой программы.
Я думаю, что лучшим вариантом было бы использовать вместо него WatchAPI, поскольку он оборудован для обработки изменений в файле и, следовательно, недействительности частичных разрешений.

У меня тоже проблемы со скоростью. У меня есть большое приложение Angular, в котором я запускаю тесты транспортира с фреймворком jasmine. Когда я запускаю тесты с флагом транспортира —troubleshoot, я вижу, где он доходит до точки, в которой файлы обрабатываются. Обычно это занимает около + — 3 секунд, и после этого начинается жасмин. Имея версию 8.0.0 и выше, требуется почти 2 минуты, пока файлы не будут обработаны и не запустится жасмин.

К сожалению, я не знаю, где можно попробовать решение с file: false. Любая помощь приветствуется.

Это не решение, но понижение до 6.2.0 помогло мне в настоящее время с проблемами производительности теста.

А пока попробуйте использовать флаг среды из https://github.com/TypeStrong/ts-node#cli -and-programmatic-options — TS_NODE_FILES=true . Я попытаюсь выполнить рефакторинг до нового API часов TypeScript и посмотрю, улучшит ли он производительность в ближайшие недели.

ts-узел 7.0 — 2.5с
ts-узел 8.0 — 5.2 с

в той же среде.

@ miao17game В той же среде, это набор тестов, скрипт или что-то еще?

Привет — чего стоит —

У нас довольно большая кодовая база (точно не знаю …)

Это порядка 450 тестов Mocha.

7.x запускался не сразу, но терпимо.

Я обновился с 7.0.2 до 8.0.1, и тесты на Windows никогда не заканчиваются. Они отлично работают в Linux (например, 7.x).

Прочитав это, я попытался использовать флаг --files true . На меньшей кодовой базе это сильно изменилось (тесты прошли).

На базе кода с 450 тестами … он просто так и не закончился. Странно то, что если я установил переменную окружения TS_NODE_FILES — set TS_NODE_FILES=true ; тесты начинаются практически сразу.

Если это поможет:

mocha --recursive --require ts-node/register -R spec ./**/*.spec.ts --no-timeouts --exit

tsconfig.json

{
  "compilerOptions": {
    "target": "es6",
    "outDir": "dist",
    "rootDir": "src",
    "moduleResolution": "node",
    "module": "commonjs",
    "declaration": true,
    "importHelpers": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "sourceMap": true,
    "listFiles": false,
    "traceResolution": false,
    "pretty": true,

    "strictNullChecks": true,
    "forceConsistentCasingInFileNames": true,
    "noFallthroughCasesInSwitch": true,
    "noImplicitAny" : true,
    "noImplicitReturns": true,
    "noImplicitThis": true,
    "noUnusedLocals": false,
    "noUnusedParameters": false,

    "typeRoots": [
      "node_modules/@types"
    ],
    "lib": [
      "es2018",
      "es6",
      "dom",
      "dom.iterable"
    ]
  },
  "include": [
    "src/**/*.ts"
  ],
  "exclude": [
    "node_modules/**"
  ],
  "compileOnSave": false
}

package.json

    "ts-node": "^8.0.2",
    "typescript": "3.3.3"
    "tslib": "^1.9.3",

Мы только начали сталкиваться с этой проблемой после обновления нашего приложения Angular до 7.2.5, и в то же время мы также обновили ts-node до 8.0.2. После обновления запуск тестов транспортира e2e всегда занимал около 2 минут, прежде чем они начали работать. После некоторого расследования я обнаружил, что загрузка файлов спецификаций занимала много времени. Мне пришлось понизить версию ts-node до 5.0.1, которая это исправляет, но просто интересно, была ли у кого-нибудь такая же проблема и смогли ли они решить ее с помощью последней версии ts-node.

Я сталкиваюсь с этой проблемой при написании тестов с использованием mocha + proxyquire.
Мое решение пока состоит в том, чтобы смоделировать как можно больше зависимостей с помощью proxyquire и использовать эти три варианта для ts-node (все они, похоже, положительно влияют на скорость запуска):

transpileOnly: true,
typeCheck: false,
files: false

@kaiza устанавливает эту переменную среды -> set TS_NODE_FILES=true

Это должно ускорить ваши тесты

Мне было интересно, исправлено ли это в новом выпуске (8.0.3).
У нас есть тестовый набор из почти 8000 тестов, и с версией 7 требуется всего несколько секунд, прежде чем он начнется, но когда я обновился до версии 8, до начала тестов потребуется более 30 секунд.

Для справки: кодовая база составляет около 70 тысяч строк кода, тестовая кодовая база — это что-то более 110 тысяч строк кода. Всего почти 1800 файлов.

@chadbr У меня тоже проблема с этим, я попробовал предложенное вами исправление, добавив переменную среды, которая, к сожалению, не работала с ts-node 8.0.3

@blakeembrey Я [email protected] в моем проекте монорепозитория (https://github.com/just-dandi/dandi). Я обновился с 7.0.1 до 8.0.3 в этой ветке: https://github.com/just-dandi/dandi/tree/feature/9-pg-db-tests , и каждый раз, когда я запускаю свой набор тестов, он сейчас занимает около 30 секунд. Для сравнения, в 7.0.1 он будет работать примерно через 6 секунд после того, как кеш ts-node нагреется.

Я пробовал использовать TS_NODE_FILES=true , но ничего не помогло.

Если вы хотите попробовать проверить эту ветку, просто запустите npm run setup после клонирования, и тогда вы сможете запускать тесты с помощью npm test .

Я просто использую tsc --noEmit && TS_NODE_TRANSPILE_ONLY=true ts-node index.ts в своем проекте, и это в 3 раза быстрее, чем ts-node index.ts (в моем проекте более 500 файлов ts. До: 96 секунд, после: 32 секунды).

также пришлось понизить 8.0.3 до 7.0.1 чтобы исправить проблему с производительностью, время для начала тестов было примерно 3 минуты против нескольких секунд разницы, TS_NODE_FILES=true ничего не помогло

Нам тоже пришлось понизить рейтинг. Вот что происходит в нашем проекте 💥

7.0.1

8.0.3

Воспроизведение проблемы

Я также создал проект для воспроизведения проблемы: https://github.com/lukaselmer/reproduce-slow-ts-node

7.0.1

git clone https://github.com/lukaselmer/reproduce-slow-ts-node reproduce-slow-ts-node-v7
cd reproduce-slow-ts-node-v7
npm i
npm start
npm start

8.0.3

git clone https://github.com/lukaselmer/reproduce-slow-ts-node reproduce-slow-ts-node-v8
cd reproduce-slow-ts-node-v8
git checkout v8
npm i
npm start
npm start

С TS_NODE_FILES = true

С TS_NODE_TRANSPILE_ONLY = true

При TS_NODE_FILES = true TS_NODE_TRANSPILE_ONLY = true

Кажется, что даже с дополнительными опциями 8.0.3 все равно в 2-7 раз медленнее, чем 7.0.1 .

Кажется, это не исправлено в версии 8.1.0 😞

У меня также возникают проблемы с производительностью при выполнении тестов с лентой и ts-node 8.1.0 . С опцией TS_NODE_TRANSPILE_ONLY=true тесты выполняются в 6 раз быстрее, тогда как TS_NODE_FILES=true не оказывает положительного влияния.

@lukaselmer Я пробовал вашу ветку, но на самом деле она не проверяет медлительность, за исключением использования кеша файловой системы. Если вы сделаете --no-cache вы получите тот же результат. Я не уверен, скольким людям требуется одно и то же содержимое файла снова и снова — если да, мы можем сделать для этого кеш в памяти, но я подозреваю, что здесь есть другая проблема, не отраженная в вашей демонстрации. Если вы выполните ts-node --no-cache в версии 7, вы увидите аналогичные показатели производительности.

@sheetalkamat FWIW, я пробовал различные варианты, упомянутые на этой странице, но ни один из них не соответствует требуемому варианту использования ts-node . Режим просмотра 100% не работал, потому что мне нужно 1. получить исходный файл, который всегда был пуст, чтобы иметь возможность испускать конкретный файл, и 2. он взял на себя консоль для вывода отладочных операторов TypeScript. Я также не думаю, что просмотр файлов необходим в ts-node , проблема скорее в том, что компилятор TypeScript заставит весь проект повторно вычислить, если изменится массив корневых файлов (IIRC).

@weswigham @sheetalkamat Одно большое отличие от perf — вывод всех имен файлов вместо имени корневого файла (https://github.com/TypeStrong/ts-node/commit/6dad5ad34d0cea80ff9be75d9a77e07f19d9175a) — любые идеи, почему это имеет такое огромное значение в исполнении? Помимо этого, я пошел дальше и добавил кеширование ко всем операциям FS (https://github.com/TypeStrong/ts-node/commit/1e838f76a3b3590b3ee37acfcb9d846a4e0bd08d) — это имеет большее значение для людей, использующих не SSD, но я обнаружил в В простом примере выше он делает более 1400 запросов к «каталог существует», 700+ к «файлу существует», 170+ к «чтению файла» и т. д. Есть какие-нибудь подсказки о том, почему это необходимо для компилятора? Похоже, много поисков — при кешировании они сокращаются всего до 40 операций в секунду.

Не стесняйтесь попробовать 8.2.0, в нее внесены два незначительных улучшения, описанных выше. Это никуда не годится, как простое повторное использование кэшированного испускания несколько раз, поскольку не должно быть слишком распространенным, что файлы людей в их проекте одинаковы.

Есть какие-нибудь подсказки, почему это необходимо для компилятора? Похоже, много поисков — при кешировании они сокращаются всего до 40 операций в секунду.

AFAIK мы ожидаем, что предоставленный CompilerHost реализует соответствующее кеширование (встроенное, основанное на sys , нет) — у нас фактически есть набор кеширующих хостов компилятора, которые мы используем для режима tsc -b языковая служба.

@blakeembrey, как предложил @weswigham , мы хотим, чтобы CompilerHost поддерживал все кеши. Улучшения, которые вы видите, я думаю, из-за разрешения модуля, поскольку это то, что требует от нас запроса каталога / файла в нескольких местах.
Для API часов вы хотите предоставить реализации watchFile и watchDirectory которые уведомляют часы об изменениях. Например. https://github.com/sheetalkamat/ts-loader/blob/master/src/servicesHost.ts#L458, где он создает наблюдателя, а известное состояние измененных файлов / каталогов webpack уведомляется о просмотре на https: // github. com / sheetalkamat / ts-loader / blob / master / src / watch-run.ts # L51.

@lukaselmer Я пробовал вашу ветку, но на самом деле она не проверяет медлительность, за исключением использования кеша файловой системы. Если вы сделаете --no-cache вы получите тот же результат. Я не уверен, скольким людям требуется одно и то же содержимое файла снова и снова — если да, мы можем сделать для этого кеш в памяти, но я подозреваю, что здесь есть другая проблема, не отраженная в вашей демонстрации. Если вы выполните ts-node --no-cache в версии 7, вы увидите аналогичные показатели производительности.

Я согласен, что с ts-node --no-cache загрузка файлов с версией 7 занимает больше времени. Я также пробовал это в нашем проекте.

• 7.0.1 нормально (с использованием кеша): запуск сервера: 1053.921 мс
• 7.0.1 без кеша ( ts-node --no-cache ): запуск сервера: 24118,856 мс
• 8.2.0 нормальный: запуск сервера: 13705.785 мс
• 8.2.0 --no-cache команда не существует
• 8.2.0 с TS_NODE_TRANSPILE_ONLY = true: запуск сервера: 3117,804 мс

Кэш файловой системы уже реализован в 8.2.0 , верно? Были ли другие активные кеши в 7.0.1 ? 🤔

@lukaselmer Кэш 7.x описывает не кэширование операций файловой системы, а кеширование и контрольную сумму результатов компилятора TypeScript. Это нестабильно, поскольку изменение суб-суб-зависимости может привести к сбою текущего файла, но при использовании кеша это останется незамеченным (потому что файл не изменился). Правильным решением будет что-то вроде нового инкрементального TypeScript, когда он будет открыт.

@blakeembrey Спасибо за объяснение.

У меня также возникают проблемы с производительностью при выполнении тестов с лентой и ts-node 8.1.0 . С опцией TS_NODE_TRANSPILE_ONLY=true тесты выполняются в 6 раз быстрее, тогда как TS_NODE_FILES=true не оказывает положительного влияния.

@kiliw : Это отключает проверку типов в файлах спецификаций. Если вы используете какие-либо типы машинописных текстов в своих тестовых файлах, они не будут проверяться.

@ vort3xxx спасибо за информацию

Та же проблема, tsc занимает 9 секунд для компиляции всего проекта, запуск только подмножества тестов занимает 25 секунд, чтобы их запустить …
последний ts, последний мокко, последний ts-узел, все самое последнее

Для тех, кто хочет очень быстро запустить свои тесты мокко, пока эта проблема не будет исправлена, вы можете:

• запустить tsc --watch в окне консоли
• измените свою тестовую команду, чтобы запускать тесты из вывода js
• больше не регистрировать ts-node, чтобы избежать медлительности

Таким образом, вы можете написать свой ts-тест, он автоматически компилируется в js, и когда вы запустите тестовую команду, она выполнит ее очень быстро.

У меня странная проблема, когда

console.log(new Date())
import * as express from 'express'
console.log(new Date())

в моем проекте уходит 2 секунды, а в чистом — всего несколько мс.

Я также заметил, что TS_NODE_TRANSPILE_ONLY=true делает его медленнее, а TS_NODE_FILES=true , похоже, ничего не делает.

Любые идеи?

    "ts-node": "^8.1.0",
    "typescript": "^3.4.5",

{
  "compilerOptions": {
    "module": "commonjs",
    "target": "es2016",
    "noImplicitAny": false,
    "sourceMap": true,
    "noUnusedParameters": true,
    "noUnusedLocals": true
  }
}

ts-node index.ts

Обновлять:

ts-node @ 7 кажется во много раз быстрее

Я прочитал все комментарии, вопрос все еще открыт, и прошло уже около 9 месяцев. В последней версии все еще есть эта проблема, и единственное решение, которое я вижу здесь, — это вернуться к 7.0.1.

Есть ли обновления по этой проблеме и когда она будет решена.

ts-node -r tsconfig-paths/register --files run-tests.ts | faucet

Использование --files помогает моему коллеге запускать тесты немного быстрее, но для меня они не завершаются даже через 11 минут, пока я заваривал чай.

@gruckion Если вы хотите, чтобы он был улучшен, вам нужно отправить PR. Основываясь на этом обсуждении, мне неясно, как улучшить производительность — единственные возможные конфигурации: --files или --transpile-only . Единственная серьезная проблема, которую я могу понять из комментариев, заключается в том, что людям очень понравился кеш файловой системы, который можно было повторно включить, но не по умолчанию, потому что это вызывает тонкую проблему, которую трудно отладить. Использование новой инкрементной компиляции с помощью TypeScript будет стабильным, и я бы хотел, чтобы это было реализовано, я думаю, что это разрешит этот поток!

Использование новой инкрементной компиляции с помощью TypeScript было бы более стабильным, и я бы хотел, чтобы это было реализовано, я думаю, это разрешит этот поток!

Прохожие, заинтересованные в реализации этого, вот объявление со ссылкой на PR & docs: API TS 3.6 для поддержки --build и --incremental .

Некоторое время пользуюсь 8.3.0. Пытался обновиться до 8.4.1 сегодня, время запуска увеличилось с ~ 16 до ~ 75 с.

А что с 8.4.0? Есть только изменение кода, основанное на производительности, и его пришлось отменить, потому что это вызвало ошибки типа, которых не должно было происходить.

Просто попробовал 8.4.0, и все нормально запускается

Конечно. Все еще вижу медленный запуск в этой ветке

@connorjayfitzgerald Вот почему проблема все еще не

есть ли способ сравнить профилирование производительности из 8.4.0 и 8.4.1, чтобы понять, что вызывает проблему?

@DanielSchaffer Я хотел бы помочь с этим, есть только одно изменение (https://github.com/TypeStrong/ts-node/commit/87a6e2c5d73a43610bf21abde710a6c9ae973756), и оно было возвращено для исправления https://github.com/TypeStrong/ts -узел / вопросы / 884. Неясно, как это негативно повлияло на вещи, и также неясно, почему изменения в инкрементной программе не происходят быстрее (они есть в наборе тестов).

может быть:

tsnode --optimistic

?

Я могу подтвердить большую разницу в производительности между 8.4.1 и 8.4.0

мой стартовый сценарий

cross-env NODE_ENV=development nodemon --inspect --watch src -r dotenv/config -r ts-node/register src/index.t

и tsconfig

{
"compilerOptions": {
    "esModuleInterop": true,
    "target": "es6",
    "module": "commonjs",
    "outDir": "./dist",
    "sourceMap": true,
    "noImplicitAny": true,
    "typeRoots" : [
        "node_modules/@types",
        "./src/types"
    ]
},
"include": [
    "./src/**/*"
],
"exclude": [
    "node_modules"
]
}

Просто к сведению, 8.4.0 занимает ок. 5 секунд для запуска нашего приложения, а 8.4.1 требуется от 5 до 15 минут для запуска. Мы не можем поделиться кодом проекта для репликации, но, надеюсь, это дает представление о замедлении, которое он вызывает. Наш проект содержит 245 файлов .ts.

Может ли кто-нибудь из вас протестировать ветвь API инкрементного компилятора и сообщить мне, так ли медленно она работает?

@blakeembrey выглядит хорошо при использовании этого в нашем package.json :

  "ts-node": "https://github.com/TypeStrong/ts-node.git#be/incremental-program"

Отличный отзыв, спасибо! Если я смогу собрать еще один положительный отзыв о производительности в большом проекте, я рассмотрю возможность выпуска его как v9 вместе с другими критическими изменениями.

@blakeembrey Я пробовал ветвь инкрементной программы, и она запускает наше приложение за 10 или 11 секунд, тогда как 8.4.0 занимает около 16 секунд.

Я избегаю этой проблемы, разделяя компиляцию и ответ, поскольку мне все еще нужна информация о типе:

package.json (обрезанный)

    "scripts": {
        "build:dev": "NODE_ENV=development tsc --watch",
        "start": "NODE_ENV=development nodemon -q node -r tsconfig-paths/register distribution/index.js --watch"
    },

и tsconfig.json (обрезанный)

        "pretty": true,
        "noEmitOnError": true,

затем я запускаю npm run build:dev в одном разделении терминала, npm start в другом.

Это мой обходной путь, пока он не будет исправлен: man_shrugging:

@tstelzer Я тоже так делаю.

@blakeembrey Я заметил, что добавочная ветка была удалена, но я не вижу, является ли она частью выпуска? Вы сказали «v9», это все еще ваш план? Я немного разбираюсь в OC, так что удерживать посылку ломает мой мозг: D

@christianrondeau В настоящее время он находится на master но не может поддерживать вариант использования, который ранее поддерживался. Я обнаружил это только после того, как попытался протестировать другую ошибку в отставании, поэтому еще не выпустил ее. Скорее всего, я немного постараюсь поставить это за флаг как часть v8.

@blakeembrey У меня есть довольно крупная общедоступная монорепозитория всех машинописных текстов (https://github.com/just-dandi/dandi) — могу ли я чем-нибудь помочь? Я использую ts-node для запуска своих модульных тестов с mocha , и в последнее время это было довольно грубо — прошло чуть более 60 секунд с момента запуска мокко до момента, когда я начинаю видеть результаты на моем MacBook Pro 2015 года.

Для сравнения, я могу сделать новую сборку проекта (используя tsc --build ) примерно за 20 секунд. Восстановление занимает около 7 секунд.

РЕДАКТИРОВАТЬ: Похоже, это ограничено проверкой типа — использование --transpile-only по-прежнему довольно быстро

Я только что попробовал 8.5.0 (установив с использованием URL-адреса GH), и сейчас он, похоже, у меня вообще не работает — мой мокко работал в течение 5 минут, не показывая никаких результатов, прежде чем я его остановил.

Кроме того, я заметил, что когда я пытаюсь остановить процесс с помощью CTRL+C , это не всегда фактически убивает базовый процесс узла. Я не уверен, что это проблема с мокко или что-то безумное происходит с ts-node.

Когда я обновил ts-node нашего проекта с 4.1.0 до 8.5.2, я также столкнулся с вышеуказанной проблемой, поскольку время запуска нашего приложения значительно замедлилось. Как было сказано выше, использование --transpile-only значительно ускорило процесс, но я действительно не хотел терять проверку типов. Итак, пока я жду выхода более поздней версии ts-node, которая ускорит сборку нашего приложения без использования --transpile-only , я понизил версию до 7.0.1. Эта версия дает мне быстрое время сборки (потому что, например, она кеширует части предыдущих результатов сборки).

Когда я обновил ts-node нашего проекта с 4.1.0 до 8.5.2, я также столкнулся с вышеуказанной проблемой, поскольку время запуска нашего приложения значительно замедлилось. Как было сказано выше, использование --transpile-only значительно ускорило процесс, но я действительно не хотел терять проверку типов. Итак, пока я жду выхода более поздней версии ts-node, которая ускорит сборку нашего приложения без использования --transpile-only , я понизил версию до 7.0.1. Эта версия дает мне быстрое время сборки (потому что, например, она кеширует части предыдущих результатов сборки).

Я сделал то же самое. У меня была довольно старая версия (3.3.0), и я был очень удивлен, насколько плохая производительность при запуске на 8.x. К сожалению, мне тоже пришлось перейти на более раннюю версию.
@blakeembrey , есть ли дополнительная информация о том, когда новая версия улучшит эти проблемы с производительностью?

Тем не менее, ода вам @blakeembrey и остальной команде ts-node. Мы высоко ценим вашу работу над этим бесплатным инструментом с открытым исходным кодом и вашу видимость / доступность для его пользователей.

Пробовал все версии с 3 по 8. И некоторые версии nodemon 1-2.
Windows 7 и 10: сборка может занять 10 секунд. Но часто на сборку уходит 4-5 часов (даже на перестройку после одного единственного изменения).
Способы из этой темы пока не помогают.
~ 2100 ts файлов

Но у коллег с Mac этой проблемы нет. Или не заметил.
Спасибо.

Это займет у нас 10 секунд — 1 час, если мы используем ts-node 3. * с добавленными настройками в tsconfig.json :

    "pretty": true,
    "noEmitOnError": true,

Думаю, у меня был прорыв. Компиляция становится намного быстрее, если мы реализуем getProjectVersion в нашем LanguageServiceHost . Я думаю, что без реализации этого метода у компилятора нет другого выбора, кроме как регулярно отбрасывать кучу внутреннего состояния. Например, для каждого необходимого ts-файла мы выполняем 2 вызова подряд : один для получения выходного JS, а другой — для диагностики. Без реализации getProjectVersion компилятор должен переделать кучу внутренней работы для обоих этих вызовов, что безумие, потому что ничего не изменилось.

Например, если вы запустите следующее утверждение:

assert(languageService.getProgram() === languageService.getProgram())

… сегодня он не работает в ts-node, но он проходит, когда я добавляю реализацию getProjectVersion() .

Источник TS, объясняющий getProjectVersion()

РЕДАКТИРОВАТЬ: вот где это происходит внутри компилятора: https://github.com/microsoft/TypeScript/blob/master/src/services/services.ts#L1201 -L1394
Если версия проекта не совпадает или не реализована, необходимо создать новые Program и TypeChecker .
Реализовано и объяснено здесь: https://github.com/Microsoft/TypeScript/pull/3131/#issuecomment -103121030

Даже когда мы не предоставляем версию проекта, языковая служба внутренне проверяет, обновлена ​​ли программа, используя более интенсивную проверку ЦП, перебирая все файлы, значения конфигурации и т. Д., Чтобы увидеть, не изменилось ли что-нибудь. Эта проверка не выполняется, значит, мы делаем что — то
https://github.com/microsoft/TypeScript/blob/master/src/compiler/program.ts#L555 -L650

EDIT2: обнаружено, где он не работает. Когда какие-либо исходные файлы опущены в getScriptFileNames проверка не выполняется, потому что во внутреннем HostCache этих файлов нет. Вызвано откатом между
https://github.com/TypeStrong/ts-node/issues/754#issuecomment -536097118
Может быть, связано: https://github.com/TypeStrong/ts-loader/issues/949

Я зарегистрировал ошибку в Typescript, чтобы узнать, является ли аннулирование Program ошибкой с их стороны.
https://github.com/microsoft/TypeScript/issues/36748

@cspotcode Этот код является преднамеренным и основан на реализации машинописного текста (насколько я мог понять в то время). Вам нужно создать новую программу, когда файлы расширяются в объеме, но она построена на основе старой программы, поэтому не должна быть такой медленной. Компилятор инкрементной сборки использует тот же экземпляр под капотом, но сначала читает файл сборки TS. Конечно, я тоже мог это неправильно реализовать.

@blakeembrey спасибо, я учусь тонну , как я копаться в источнике TS, и я не смотрел на это немного еще.

Возможно, я обнаружил ошибку TS (microsoft / TypeScript # 36748), так что скрестив пальцы, они скоро вернутся ко мне. В любом случае, я думаю, мы можем обойти ошибку, реализовав getProjectVersion() . И я не уверен, что это даже влияет на путь кода инкрементной сборки. Узнать больше …

Мы также столкнулись с этой проблемой, и это препятствует запуску нашего API в течение 60-секундного тайм-аута heroku для команды запуска dyno. Странно то, что тот же код запускается менее чем за 5 секунд с использованием ts-node-dev . Это использует "ts-node": "^8.6.2", "ts-node-dev": "^1.0.0-pre.44"

В нашем случае использование --transpile-only или --files false помогает.

@jamemackson, у нас была такая же проблема. решение было понизить до 7

@jamemackson @brunolm Я почти уверен, что медленность должна быть значительно уменьшена с помощью только транспиляции. Вы абсолютно уверены, что ts-node правильно интерпретировал флаг --transpile-only и переключился на использование ts.transpileModule ? Похоже, что с флагом что-то пошло не так, поэтому он не переключился в режим только транспиляции, поэтому он оставался медленным.

@jamemackson @brunolm Я почти уверен, что медленность должна быть значительно уменьшена с помощью только транспиляции. Вы абсолютно уверены, что ts-node правильно интерпретировал флаг --transpile-only и переключился на использование ts.transpileModule ? Похоже, что с флагом что-то пошло не так, поэтому он _не__ переключился в режим только транспиляции, поэтому он оставался медленным.

@cspotcode Знаете, как это проверить? Я просто попробовал запустить его в heroku с флагом и сравнил время, но не имею никакого представления о том, что происходит внутри.

@jamemackson К сожалению, я не знаю отличного способа включить подробное ведение журнала с ts-node. Вероятно, нам следует добавить какой-то флаг ведения журнала отладки, который выводит подробную диагностику.

Вы можете ввести преднамеренную ошибку типа, которая не повлияет на ваш проект. transpile-only разрешит это, но non-transpile-only вызовет ошибку типа. Например const a: number = 'this is a string';

РЕДАКТИРОВАТЬ: вы также можете обернуть наш хук require для регистрации информации о времени, хотя это не скажет вам, соблюдает ли ts-node флаг transpileOnly.

const orig = require.extensions['.ts'];
require.extensions['.ts'] = function(module, filename, ...rest) {
    const message = `.ts require hook for ${ filename }`;
    console.time(message);
    try {
        return orig.call(this, module, filename, ...rest);
    } finally {
            console.timeEnd(message);
    }
}

@jamemackson Как вы используете ts-node ? Если вы используете его через --require с исполняемым файлом узла, вам может потребоваться использовать точку входа регистрации transpile-only вместо флага: --require ts-node/register/transpile-only

флаг для запуска подробной диагностики было бы здорово.

Простите меня, поскольку я почти ничего не знаю о внутреннем устройстве этого, но чего я не понимаю, так это того, что если ts-node-dev использует ts-node под капотом, почему он все еще работает быстро при использовании того же ts-node версия, которая работает очень медленно при самостоятельном запуске 🤔

➜  api git:(test-performance) ✗ yarn start:dev
yarn run v1.22.0
$ ts-node-dev app/server.ts
Using ts-node version 8.6.2, typescript version 3.7.5

@DanielSchaffer, мы запускаем ts-node app/server.ts в нашем стартовом скрипте.

@jamemackson ts-node app/server.ts не будет работать в режиме только транспиляции. Есть ли что-то еще, что вы делаете, чтобы перевести его в режим только транспиляции? В основном я пытаюсь понять , что именно происходит в вашей ситуации, но я думаю, что для этого требуется больше информации.

Похоже, что ts-node-dev использует какой-то слой кеширования. Я ничего об этом не знаю: не знаю, что он делает, что хранит или когда он недействителен. Так что я не знаю, как это влияет на производительность, если вообще влияет.

Извините, это наш обычный сценарий запуска, я добавил к нему аргумент --transpile-only , когда тестировал его.

@jamemackson Я слишком рано заговорил об отладке. Существует переменная env TS_NODE_DEBUG, которую вы можете установить для получения дополнительных выходных данных от ts-node. Это не документировано и не регистрирует много, поэтому нам, вероятно, придется добавить больше операторов журнала.

Спасибо @cspotcode. Я отправил вам несколько журналов по электронной почте. Я надеюсь, что это помогает! Спасибо за вашу помощь!

963 реализует getProjectVersion , что должно обойти microsoft / TypeScript # 36748, то есть компилятору необходимо выполнять проверку типов в 3 раза меньше, чем раньше. Это повлияет на вас, только если вы не включили transpileOnly / --transpile-only / TS_NODE_TRANSPILE_ONLY или compilerHost / --compiler-host / TS_NODE_COMPILER_HOST .

Если вам действительно интересно или любопытно, вы можете проверить это, поместив это в свой package.json deps: "ts-node": "https://github.com/TypeStrong/ts-node.git#ab/add-getprojectversion",

Установка TS_NODE_DEBUG=true вызовет дополнительные отладочные операторы, связанные с тем, когда и как часто компилятор должен перестраивать проверку типов.

Я копаюсь в кодовом пути, который использует API инкрементного компилятора. Это было очень медленным для моего воспроизведения ( ссылка ), как секунда на require() , потому что для каждого отдельного изменения Program он повторно анализировал все экземпляры SourceFile . Наш неинкрементный кодовый путь использует LanguageService , который использует DocumentRegistry для их кеширования.

Для инкрементного компилятора мы должны передать CompilerHost , у которого есть метод getSourceFile . Это всегда возвращало новый экземпляр SourceFile . Я не знаю, является ли это предполагаемым поведением или есть способ кэшировать экземпляры SourceFile . (или если я что-то не так делаю в своих экспериментах)

Я тестировал ветку, и она мне очень помогает!

Мои результаты:

• с ts-node v8.6.2 : умножить на 32,56 / 32,67 / 31,71 => в среднем 32,31
• с исправлением: раз 23,84 / 23,28 / 23,70 => в среднем 23,61

Еще большее улучшение достигается при использовании опции --watch mocha, которая повторно запускает тесты при изменении файлов:

• с ts-node v8.6.2 : время от сохранения файла до начала повторного запуска теста ~ 15 с
• с исправлением: время от сохранения файла до начала повторного запуска теста ~ 2 с (при первом повторном запуске немного больше, ~ 3,5 с)

Технические подробности
ОС: macOS v10.14.6

Версия узла: v13.8.0

Тестовая команда: cross-env NODE_PATH=src NODE_ENV=test TS_NODE_FILES=true mocha --exit -r ts-node/register --extension ts "test/<em i="27">*/</em>.ts"

Отличная работа, спасибо!

Я использую nodemon и tsnode

Я обновился до «ts-node»: «^ 8.6.2», и при каждом перезапуске требуется много времени для компиляции!

При TS_NODE_FILES = true никаких улучшений не наблюдалось.

Я попробую перейти на предыдущую версию «ts-node»: «^ 7.0.1» или 8.4.0, поскольку @christianrondeau, упомянутый в версии 8.4.1,

Мой проект с закрытым исходным кодом был недавно обновлен с настраиваемой конфигурации веб-пакета на использование angular-cli в качестве средства выполнения задач, и одна поразительная вещь, которая произошла, заключалась в том, что время компиляции его машинописного текста сократилось, например, с 12 минут до 3 минут.

Различия были действительно незначительными, и одна вещь, которая подмигнула мне, — это способ отправки файлов в tsc. В моей старой версии проекта я использовал маски подстановки файлов для загрузки файлов, например, src/**/*.spec.ts . В новом коде на основе angular-cli инструмент генерирует файл webpack.config по запросу, и в нем есть явный массив строк имени файла, которые передаются в качестве аргументов компилятору. Каждая позиция — это полное имя файла.

Похоже, что проекты с большим количеством файлов начали проверку типов намного медленнее незадолго до выпуска typescript 3.x, и команда angular, возможно, нашла способ вернуть некоторую производительность с помощью этого явного трюка со списком файлов.

Возможно, этой команде стоит провести сравнительный анализ списка файлов и множества файлов, чтобы увидеть, влияет ли это поведение на этот проект.

Привет @brunolm!

Как вы вообще измеряете время выполнения?

8.4.0 у меня работает нормально, разницы с 7.0.1 не замечаю,
8.6.2 очень медленный. Я еще не пробовал v8.7.0

У меня есть один большой проект, которым, к сожалению, я не могу поделиться. Точка входа — «старт».

"start": "ts-node src/index.ts"

В верхней части этого файла (после многих операций импорта) у меня есть console.log(new Date())

Тогда я бегу

date; npm start

И оттуда я получаю разницу.

✅ [email protected]

• 10 с
• 9 с
• 9 с

Выпущен как 8.8.0, дайте мне знать, если кто-нибудь увидит регресс в других частях приложения (или ошибки с TypeScript, как это произошло в 8.4.0).

Большое спасибо вам, долго решали эту проблему! Я еще не пробовал 8.8.0, но реакция людей на этот момент убедила меня, что вы действительно решили проблему.

Ṣeun pupọ ! Большое спасибо!

( Обновление: разрыв в производительности с v7 намного меньше с холодным дисковым кешем. Я думаю, что все-таки обновлюсь до v8.8.1. Для потомков я использую macOS 10.15.3, MacBook Pro 15 в конце 2013 года с SSD.)

Привет, если вы предпочитаете, чтобы я открыл другую проблему, дайте мне знать, но для моего проекта ( который является открытым исходным кодом , так что ура, чтобы иметь возможность воспроизвести!), Ни версия 8.8.1, ни возврат к версии 8.4.0 не так велики, как повышение производительности при возврате к версии 7.0.1.

Однако я думаю, что мой случай отличается от других, потому что мой проект очень маленький, и его компиляция занимает всего пару секунд, независимо от того:

• ~ 2.0s @ v8.7.0 — v8.8.1 (улучшение по сравнению с v8.6, отличная работа!)

  • ~ 1,2 с с TS_NODE_TRANSPILE_ONLY=true

• ~ 2.3s @ v8.4.1 — v8.6.2

  • ~ 1,2 с с TS_NODE_TRANSPILE_ONLY=true

• ~ 2.2 с @ v8.4.0

  • ~ 1,2 с с TS_NODE_TRANSPILE_ONLY=true

• ~ 1.9s @ v7.0.1 (первый раз после редактирования любого из моих файлов .ts )

  • ~ 1.1 с TS_NODE_TRANSPILE_ONLY=true

• ~ 0.8s @ v7.0.1 (последующие прогоны, что не очень полезно)

  • ~ 0,8 с с TS_NODE_TRANSPILE_ONLY=true

Есть ли причина, по которой мне не следует пока просто придерживаться версии 7?

В проекте, над которым я работаю, я заметил проблему с ts-node 8.8.1 и машинописным текстом 3.8.3.

Мы использовали ts-node v7.0.1 и typescript 3.5.3, и для запуска ts-node требовалось 22 минуты на репозиторий клонирования.
Благодаря v8.8.1, все еще с проверкой типов и машинописным текстом 3.5.3, для запуска требуется 38 секунд.

Однако при обновлении машинописного текста до версии 3.8.3 для запуска требуется 7 минут.
При переходе на Машинопись v3.7.5 он снова работает на 38s.

Используя TS_NODE_DEBUG в версии v3.8.3, я могу увидеть те же симптомы, что и раньше. следующие строки очень медленно обрабатываются.

ts-node invariant: Is service.getProject() identical before and after getting emit output and diagnostics? (should always be true)  true
ts-node module._compile ….

Чтобы уточнить, что вы имеете в виду, когда говорите, что эти строки обрабатываются медленно? Вы имеете в виду, что все, что происходит после появления этих строк, занимает много времени, или все, что происходит непосредственно перед появлением этих строк, занимает много времени?

Было бы полезно, если бы наш журнал отладки включал временные метки.

Я имею в виду, что таких строк сотни, и каждая из них очень медленно обрабатывается по сравнению с предыдущей версией машинописного текста.
См. Ниже выдержку из журнала с отметкой времени.

[ts-node 2020-04-01T12:09:10.565Z] invariant: Is service.getProject() identical before and after getting emit output and diagnostics? (should always be true)  true
[ts-node 2020-04-01T12:09:10.568Z] module._compile fileA.ts
[ts-node 2020-04-01T12:09:11.736Z] compiler rebuilt Program instance when getting output for fileA.ts
[ts-node 2020-04-01T12:09:11.786Z] invariant: Is service.getProject() identical before and after getting emit output and diagnostics? (should always be true)  true
[ts-node 2020-04-01T12:09:11.788Z] module._compile fileB.ts
[ts-node 2020-04-01T12:09:13.225Z] compiler rebuilt Program instance when getting output for fileB.ts
[ts-node 2020-04-01T12:09:13.273Z] invariant: Is service.getProject() identical before and after getting emit output and diagnostics? (should always be true)  true
[ts-node 2020-04-01T12:09:13.275Z] module._compile fileC.ts
[ts-node 2020-04-01T12:09:14.595Z] compiler rebuilt Program instance when getting output for fileC.ts
[ts-node 2020-04-01T12:09:14.841Z] invariant: Is service.getProject() identical before and after getting emit output and diagnostics? (should always be true)  true
[ts-node 2020-04-01T12:09:14.845Z] module._compile fileD.ts
[ts-node 2020-04-01T12:09:16.255Z] compiler rebuilt Program instance when getting output for fileD.ts
[ts-node 2020-04-01T12:09:16.268Z] invariant: Is service.getProject() identical before and after getting emit output and diagnostics? (should always be true)  true
[ts-node 2020-04-01T12:09:16.270Z] module._compile fileE.ts
[ts-node 2020-04-01T12:09:17.718Z] compiler rebuilt Program instance when getting output for fileE.ts
[ts-node 2020-04-01T12:09:17.828Z] invariant: Is service.getProject() identical before and after getting emit output and diagnostics? (should always be true)  true
[ts-node 2020-04-01T12:09:17.892Z] module._compile fileF.ts
[ts-node 2020-04-01T12:09:19.138Z] compiler rebuilt Program instance when getting output for fileF.ts
[ts-node 2020-04-01T12:09:19.149Z] invariant: Is service.getProject() identical before and after getting emit output and diagnostics? (should always be true)  true
[ts-node 2020-04-01T12:09:19.152Z] module._compile FileG.ts

Позвольте мне знать, если вам нужно что-нибудь еще. К сожалению, я не могу поделиться проектом.

@sylc Я точно не знаю, почему он медленнее по сравнению с предыдущей версией машинописного текста. Но я могу предложить некоторое представление о том, как работает компилятор.

Program неизменен. Каждый раз, когда файл добавляется к компиляции, необходимо создать новый Program чтобы включить новый файл. Старые AST можно использовать повторно, чтобы компилятору не приходилось их повторно анализировать.

Однако проверку типов необходимо выбросить и построить новую. Это означает, что каждый раз, когда файл добавляется в программу, проверка типов должна выполняться заново. (по крайней мере, насколько я понимаю) Это необходимо, потому что любой файл может включать в себя объявления глобального типа или объединение объявлений, которое влияет на любой другой файл программы.

Если вы не указали массив "types" в своем tsconfig, возможно, компилятор должен загрузить много-много объявлений @types в дополнение к вашей кодовой базе. Это может привести к тонне проверки типов.

Это происходит каждый раз, когда он говорит «перестроенный экземпляр программы».

Этого можно избежать, если не выполнять проверку типов в режиме --transpile-only . Мы можем запустить tsc --noEmit отдельно для обработки проверки типов вместо ts-node .

Другой вариант заключается в использовании ts-node «s --files флаг охотно загружать весь код в начале, так что экземпляр программы и проверки типов не должны быть перестроен. Если в начале загружено больше файлов, тогда они не будут новыми для Программы, когда они требуют () d, и проверка типов не потребуется повторно вычислять. Если вам удастся заставить это работать, большинство строк «перестроенный экземпляр программы» должны исчезнуть.

@sylc Прямая косая черта идет от TypeScript? Одна вещь, которую мне пришлось сделать в ts-node — это перенести туда, куда мы передаем имена файлов в normalizeSlashes . Если вы готовы разветвить это репо и найти пропавшего виновника, это будет действительно полезно (поскольку я не использую Windows)!

@sylc Спасибо за исследование!

FWIW, я обычно использую WSL2 (Ubuntu), но у меня есть доступ к Windows, поэтому, если вы создадите какие-либо репродукции, я смогу запустить их локально.

Мы реализуем getProgramVersion чтобы сообщить компилятору машинописного текста, когда мы знаем, что ничего не изменилось. Машинописный текст должен выполнять !arrayIsEqualTo(program.getRootFileNames(), rootFileNames) тогда, когда мы знаем, что Program необходимо перестроить.

Интересно, означает ли несогласованность имени файла повторный синтаксический анализ всех этих исходных файлов каждый раз, когда он перестраивает Программу, вместо повторного использования старых AST? Мы добавили getProgramVersion именно по этой причине: он каждый раз повторно анализировал все исходные файлы, что и делало его таким медленным. Возможно, это все еще происходит в Windows.

@sylc отлично. Ожидает ли компилятор в Windows, что все имена файлов будут содержать обратную или прямую косую черту?

Доказывает ли воспроизведение, что ошибка вызывает замедление? Становится ли заметно быстрее при слиянии # 997?

Я думаю, чтобы воспроизвести замедление, мы можем сгенерировать пару сотен больших бессмысленных файлов Typescript. Эти файлы будут имитировать большой проект с большим количеством кода для анализа (например, каждый может содержать сотни строк while(false) {/* do nothing */} ). И у нас будет одна точка входа с сотнями операторов import . import {} from './1'; import {} from './2'; Таким образом, мы можем получить важные журналы с информацией о времени.

@cspotcode

Доказывает ли воспроизведение, что ошибка вызывает замедление? Становится ли заметно быстрее при слиянии # 997?

Я попробовал свою ветку в своем рабочем проекте и обнаружил, что скорость вернулась к нормальной, то есть такая же, как у tsc 3.7.5.
Итак, с tsc 3.8.3, 6 минут без моих изменений по сравнению с 50 с моими изменениями

Ожидает ли компилятор в Windows, что все имена файлов будут содержать обратную или прямую косую черту?

Он может обрабатывать и то, и другое, поскольку он также нормализует путь. см. некоторые связанные тесты. Я думаю, что индекс кеша потенциально может иметь обратную косую черту, если он всегда согласован. Но имеет смысл сделать все с косой чертой.

@DanielRosenwasser Я быстро попробовал ваше репо (клон, затем npm i затем nm run test или npm run build ), но я получаю некоторые ошибки ( builder не определенный). не стесняйтесь пробовать мою ветку и сообщать о времени.

Извините, что вмешиваюсь, это может быть только моим мнением, но я думаю, что исходная проблема «Компиляция невероятно медленная» исправлена. По крайней мере, по большей части все вернулось в норму.

Мне просто было интересно, следует ли закрыть эту проблему и открыть новую, чтобы заняться этой другой проблемой, о которой вы сейчас говорите. Если в этом есть смысл.

Извините, что вмешиваюсь, это может быть только моим мнением, но я думаю, что исходная проблема «Компиляция невероятно медленная» исправлена. По крайней мере, по большей части все вернулось в норму.

@brunolm Извините, я пытаюсь подписаться на эту тему, но не видел этого. Какое было исправление? Я бы с удовольствием попробовал это на своем проекте.

@sylc Я думаю, вы хотели отметить @DanielSchaffer

Хорошо, я думаю, что нашел.

Благодаря v8.8.1, все еще с проверкой типов и машинописным текстом 3.5.3, для запуска требуется 38 секунд.

Обновление с 8.6.2 до 8.8.2 , похоже, исправляет мою медлительность. Или, по крайней мере, большую его часть. У меня был единственный модуль, который сканирует. Это заняло ~ 130 мс с tsc / node и ~ 15 с с ts-node 8.6.2 . Теперь это занимает ~ 450 мс с 8.8.2 .

Я использую windows и машинопись 3.7.5

ПРИМЕЧАНИЕ. Кажется, это улучшается, только если у меня есть опция --files .

Независимо от того, была ли решена исходная проблема с медлительностью, я рад оставить этот тикет открытым еще немного, потому что обсуждение все еще полезно. В конечном итоге цель этих билетов — помочь нам улучшить ts-node, и он по-прежнему служит этой цели для меня.

Если выявляются отдельные проблемы, мы отслеживаем и исправляем их как отдельные заявки. Кроме того, недавнее изменение в 8.8.0, возможно, придется отменить, поскольку оно запускает регрессионный тест с # 884. Так что, возможно, мы еще не вышли из леса.

См. Также: # 996, где есть ссылки на другие соответствующие билеты.

Кроме того, очень полезно указать, используете ли вы Windows или нет! Поскольку кажется, что у нас может быть проблема с производительностью только для Windows, связанная с путями / vs .

@sylc извините, я только что понял, что у меня нет инструкций по настройке в README . Они должны быть в README при разработке.

Во-первых, я изначально настроен с помощью Yarn. Вы могли бы заставить его работать с npm , но вам нужно будет заменить пару использований в package.json (например, builder yarn install -> builder npm install ) и сценарий setup (например, safe_run yarn -> safe_run npm i , yarn link -> npm link , yarn install-packages -> npm run install-packages ). Не уверен, что у меня в голове есть другие.

Чтобы убедиться, что все подпроекты настроены и установлены правильно, запустите yarn setup (или npm run setup если вы решите попробовать этот маршрут). После этого yarn build и yarn test ( npm run build / npm test ) должны делать свое дело должным образом.

@cspotcode круто! Мне просто было интересно, имеет ли смысл отслеживать другие проблемы, но если этот вопрос все еще актуален, имеет смысл оставить его открытым.

В моем случае у меня были проблемы на моем компьютере (Windows 10 Pro x64), но также и на Heroku приложение занимало более 60 секунд (время ожидания по умолчанию) для запуска. Кроме того, на Mac он был медленнее (у меня сейчас нет доступа к нему, чтобы протестировать его и получить цифры).

Как я могу протестировать кешированные и некэшированные прогоны в версии 8.0+? Похоже, что в более старых версиях был флаг --cache-directory (или параметр конфигурации cacheDirectory ), который контролировал, куда помещается кеш, но они, похоже, не влияют на строку 8.x (без кеша файлы создаются). Я также не вижу никакой разницы в установке переменной TS_NODE_CACHE env.

Кеширование @DanielSchaffer когда-то было удалено. Есть планы повторно добавить его, и проблемы с отслеживанием этой работы.

Я использую node-demon с ts-node для автоматического перезапуска сервера при редактировании кода. Я все еще вижу последовательное 10-кратное замедление перезапуска между версиями v7.0.1 и v8.10.1 из ts-node . Я использую Linux Mint.

Я попытаюсь создать минимально воспроизводимый пример, но я просто хотел отметить, что регресс скорости все еще очень очевиден, по крайней мере, на моей машине.

@martinblostein не могли бы вы поделиться настройками своей среды? Им это может быть полезно.
ОС, версия узла, версия npm и т. Д.

@martinblostein Я подозреваю, что это быстрее, потому что у вас включено кеширование в 7. Это было удалено в 8.
См. # 701, чтобы узнать, почему.

Чтобы эффективно сравнить производительность, можете ли вы попробовать еще раз, установив для переменной среды TS_NODE_CACHE значение false .

@cspotcode Ах, да, вы правы. Если я отключу кеширование, то версия v7 займет столько же времени, сколько v8.

Я думаю, что мы будем придерживаться v7, не забывая об этом. Спасибо, что обратили на это мое внимание!

Я вижу, что этот поток не был активен в течение нескольких месяцев, но я испытываю чрезвычайно медленные модульные тесты при использовании mocha + ts-node. Кто-нибудь выяснил первопричину?

Я безуспешно пробовал многие из приведенных выше предложений, включая параметры только для транспиляции и файлов. Я также заметил, что запуск одного теста сам по себе выполняется быстро (с использованием обозревателя тестов mocha в vscode), но запуск всех тестов вместе очень медленный (~ 2 секунды на тест). Таким образом, кажется, что mocha + ts-node может повторно компилировать все тестовые файлы для каждого теста. Есть ли способ этого избежать?

@ david-wb Mocha и ts-node по умолчанию не перекомпилируют файлы повторно; в ваших тестах должно быть что-то еще, вызывающее это. Без примера мы не можем знать, поэтому, если это вас беспокоит, я рекомендую поделиться более подробной информацией.

Другая возможность, возможно, вы не включили режим только транспиляции. Если вы думали, что это так, но на самом деле этого не произошло, это объясняет, почему скорость не стала быстрее. Может быть, флаг был передан неправильно и т. Д. Без примера не могу сказать.

970 и # 1092 должны ускорить инкрементную компиляцию, сделав нас умнее в изменении корневых файлов.

В # 908 есть готовое решение для кеширования, которое вы можете попробовать сегодня. Вы также можете помочь нам повторно добавить кеширование в качестве встроенной функции ts-node.

Если вы хотите помочь, дайте нам знать, и мы поможем вам найти эти билеты.

При использовании ts-node 7.0.1 в настоящее время для загрузки нашего API требуется 15+ минут! --transpile-only помогает со скоростью, но проверка типов необходима для нас, поэтому я не могу использовать --transpile-only .

@sandorvasas
Зачем использовать ts-node v7 вместо v9? Вам что-то мешает использовать v9?

Что вы используете для проверки типов сегодня? Я предполагаю, что вы используете tsc --noEmit . Это работает для вас?

@sandorvasas вам удалось попробовать версию 9?

@cspotcode, стоит ли ожидать повышения производительности в версии 9? Я не вижу ничего подобного в журналах изменений, хотя я только что запустил его в одном из моих проектов, с которым у меня проблемы с производительностью при использовании старых версий, и компиляция, безусловно, ускорилась, даже сейчас работает быстрее, чем ts-node-dev, впечатляюще!

@mewtlu , приятно это слышать. Мы исправили несколько проблем, которые, как мне кажется, заставляли TS без необходимости повторять кучу работы, поэтому вы можете извлечь выгоду из этих изменений.

Например, мы лучше отслеживаем, какие файлы уже загружены компилятором, поэтому мы можем избежать изменения программы для принудительного их включения. Это приводило к дублированию работы внутри компилятора.

Я только что попробовал 9, и хотя он кажется несколько быстрее при начальной компиляции, он перекомпилируется почти с той же скоростью, что и исходная при изменении файла, что в целом делает его гораздо менее пригодным для использования, чем v7 (необходимо подождать 4 минуты, чтобы перекомпилировать после изменения один символ в коде). Я вернулся на v7.

Я думаю заменить комбинацию простых tsc -w и nodemon на "incremental": true .

Мне нравится использовать ts-node, но он задает 8 секунд для запуска нашего API, тогда как 3 секунды для простого tsc .

@ acro5piano, не могли бы вы объяснить, как вы это делаете, пожалуйста 🙏

@ acro5piano, не могли бы вы объяснить, как вы это делаете, пожалуйста 🙏

@Alexandredc вместо того, чтобы ваша конфигурация nodemon следила за вашими .ts файлами и выполняла ts-node в записи ts файл при изменениях, вместо этого вы можете запустить tsc --watch (необязательно с "incremental": true в вашем tsconfig.json ), когда файлы .ts изменяются для создания файлов js папке "outputDir" , затем запустите node / nodemon против сгенерированной записи .js file

@khaledosman @Alexandredc

Мое текущее решение — tsc + nodemon, но я все еще занимаюсь настройкой для Ava.
Обратной стороной является сложная конфигурация. ts-node и tsconfig-paths — это простая конфигурация, прекрасно работает для сопоставлений путей fs.readFile и ts и Ava. Но tsc + nodemon в 2 раза ускоряет мой проект.

Основы:

# Directory structure

repo/
   |- tsconfig.json
   |- package.json
   |- src/
   |    `- index.ts
   `- build/
        `- index.js

// tsconfig.json

{
  "compilerOptions": {
    "outDir": "./build",      // <-- important
    "noEmit": false,     // <-- important
    "allowJs": true,
    "target": "es2019",
    "lib": ["dom", "esnext"],
    "module": "commonjs",
    "declaration": false,
    "declarationMap": false,
    "sourceMap": false,
    "removeComments": false,
    "incremental": true,
    "isolatedModules": true,
    "strict": true,
    "moduleResolution": "node",
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  }
}

// package.json

  "scripts": {
    "dev": "concurrently yarn:dev:*",
    "dev:nodemon": "nodemon build/index.js",
    "dev:tsc": "tsc -w"
  },

И последнее, что нужно добавить deps:！

yarn add -D concurrently nodemon typescript

@kfrajtak
Я пробовал esbuild, и это невероятно быстро.
Я переехал к нему. Компиляция + запуск выполняется намного быстрее, чем ts-node. Спасибо.

Изменить: сейчас я использую esbuild --watch и nodemon build/out.js

Изменить 2: я пытался использовать другой проект с использованием декоратора, но его интерполяция по-прежнему отличается от исходного tsc . так что я использую tsc --watch в этом проекте.

См. Также: # 1160, который позволяет подключиться к компилятору swc через ts-node.

Я исследовал esbuild при реализации # 1160, но были ограничения производительности при компиляции файлов. # 1160 дает те же преимущества в производительности, и люди уже успешно его используют, например https://github.com/TypeStrong/ts-node/discussions/1276#discussioncomment -590910 Я рекомендую проверить это и оставить отзыв в обсуждении нить.

1160 реализует сменные трансформаторы. Трансформатор swc встроен, но любой может написать плагин для использования любого другого трансформатора. Это означает, что существующая конфигурация проекта TS — это все, что вам нужно для использования другого преобразователя, и вы получаете те же преимущества, что и ts-node: поддержка исходных карт, загрузчик ESM и т. Д.

Кроме того, для многих людей transpileOnly — это все, что им нужно. Часто они допускают ошибку конфигурации: они считают, что transpileOnly включен, но на самом деле это не так. Мы реализовали # 1243, чтобы упростить отладку ошибок конфигурации, что позволило большему количеству людей использовать transpileOnly и лучше понять свою конфигурацию.

It is impossible to build java-script stuff.
yarn run build fails with next log output:

[../../../patzilla-ui/vendor/widget/raty/jquery.raty.js] /opt/Patzilla/patzilla-ui/vendor/widget/raty/jquery.raty.js 17.5 KiB {app-standalone} {app-embedded} [depth 6] [built]
    + 372 hidden modules

ERROR in [tsl] ERROR
      TS18002: The 'files' list in config file 'tsconfig.json' is empty.
 @ /opt/Patzilla/patzilla-ui/navigator/app/document/document-controller.js 5:15-64
 @ /opt/Patzilla/patzilla-ui/navigator/app/document/index.js
 @ /opt/Patzilla/patzilla-ui/navigator/boot/loader.js
 @ /opt/Patzilla/patzilla-ui/navigator/boot/standalone.js
 @ multi /opt/Patzilla/patzilla-ui/navigator/boot/standalone

ERROR in /opt/Patzilla/patzilla-ui/navigator/components/nataraja/index.ts
Module build failed (from /opt/Patzilla/node_modules/ts-loader/index.js):
Error: error while parsing tsconfig.json
    at Object.loader (/opt/Patzilla/node_modules/ts-loader/dist/index.js:19:18)
 @ /opt/Patzilla/patzilla-ui/navigator/app/document/document-controller.js 5:15-64
 @ /opt/Patzilla/patzilla-ui/navigator/app/document/index.js
 @ /opt/Patzilla/patzilla-ui/navigator/boot/loader.js
 @ /opt/Patzilla/patzilla-ui/navigator/boot/standalone.js
 @ multi /opt/Patzilla/patzilla-ui/navigator/boot/standalone
error Command failed with exit code 2.

info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Dear Andrii,

thanks for writing in and reporting this issue to us. From reading about ts-loader in the stacktrace (thanks for that!), we conclude this is most probably related to the recent addition of TypeScript to the frontend.

With kind regards,
Andreas.

steps to reproduce:

git clone https://github.com/ip-tools/ip-navigator.git
cd ip-navigator/
git checkout 22a7c74cfe2377335ae34df0abc1e642a5595355
virtualenv --python=python2 .venv27 && source .venv27/bin/activate
pip install -e . 
pip install nodeenv
nodeenv --node=10.15.3 .nodeenv
source .nodeenv/bin/activate && npm install -g yarn && yarn install
yarn run build

Dear Andrii,

it looks like the referenced tsconfig.json file was missing completely, so we just added it with 70dfd82. Thanks for spotting this!

Please let us know whether that solves this issue for you.

With kind regards,
Andreas.

Dear Andrii,

do you have any news on this?

With kind regards,
Andreas.