Typescript: Ошибка «Невозможно записать файл ... потому что входной файл будет перезаписан».

У меня тоже такая же проблема.

--allowjs установлено? можешь поделиться проектом?

Извините, я не могу поделиться проектом, и этот флаг не установлен. Мой tsconfig.json находится выше, и мы просто используем его с VS2015 Update 3, которое обычно запускает сборку с MSBuild.

У меня есть товарищи по команде, которые жалуются на ту же проблему, которая возникает с ними в одних и тех же проектах. Я также работаю над проектом дома на другом компьютере с той же проблемой и с той же настройкой (TS 2.2.1, VS2015 U3 и т. Д.)

Вы видите такое же поведение, если создаете простой проект с такими же конфигурациями?

У нас та же проблема https://github.com/wc-catalogue/blaze-elements/issues/299, хотя с определениями типов доступ на запись

@Hotell , вы видите это без "awesome-typescript-loader"? Вы можете поделиться со мной этапами воспроизведения?

да, как вы можете видеть в проблеме, результат - второй запуск raw tsc .

просто клонируйте репо https://github.com/wc-catalogue/blaze-elements

• нажать yarn от корня
• нажмите yarn tsc -> первая компиляция (все в порядке) => первая definitions/ папка сгенерирована
• снова нажмите yarn tsc -> ошибки

У нас аналогичная проблема - та же версия машинописного текста (2.2.1) и Visual Studio 2015 (обновление 3); при первом запуске сборки ошибок нет, но после этого мы получаем сотни таких ошибок.

Похоже, что все ошибки (для нас) находятся в папке «node_modules», которую мы установили для исключения в нашем файле tsconfig.json. - Если посмотреть на похожие ошибки, кажется, что исключения не обрабатываются одинаково в этой версии машинописного текста?

Наш файл tsconfig.json:

{
  "compilerOptions": {
    "noImplicitAny": false,
    "noEmitOnError": true,
    "removeComments": false,
    "sourceMap": true,
    "target": "es5",
    "module": "commonjs",
    "moduleResolution": "node",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true
  },
  "exclude": [
    "node_modules",
    "wwwroot",
    "aot",
    "AngularApp/main-aot.ts"

  ],
  "compileOnSave": true
}

Некоторые из ошибок, которые мы получаем (все они одинаковые, но разные файлы):

Severity    Code    Description Project File    Line    Suppression State
Error   TS5055  Cannot write file 'C:/XYZ/Project.AppWeb/node_modules/zone.js/dist/zone.js' because it would overwrite input file.  TypeScript Virtual Projects     1   Active
Error   TS5055  Cannot write file 'C:/XYZ/Project.AppWeb/node_modules/events/events.js' because it would overwrite input file.  TypeScript Virtual Projects     1   Active
Error   TS5055  Cannot write file 'C:/XYZ/Project.AppWeb/node_modules/core-js/modules/_wks.js' because it would overwrite input file.   TypeScript Virtual Projects     1   Active
Error   TS5055  Cannot write file 'C:/XYZ/Project.AppWeb/node_modules/core-js/modules/_uid.js' because it would overwrite input file.   TypeScript Virtual Projects     1   Active
Error   TS5055  Cannot write file 'C:/XYZ/Project.AppWeb/node_modules/core-js/modules/_to-primitive.js' because it would overwrite input file.  TypeScript Virtual Projects     1   Active

Опять же, если мы удалим папку «node_modules», сборка будет работать один раз, но после того, как она будет воссоздана, при следующей перестройке произойдет сбой.

@Hotell, я не вижу этого локально, что мне не хватает?

c:\test\14538\blaze-elements>yarn tsc
yarn tsc v0.18.1
$ "c:\test\14538\blaze-elements\node_modules\.bin\tsc"
Done in 5.46s.

c:\test\14538\blaze-elements>yarn tsc
yarn tsc v0.18.1
$ "c:\test\14538\blaze-elements\node_modules\.bin\tsc"
Done in 5.87s.

c:\test\14538\blaze-elements>dir /B definitions
packages
polyfills.d.ts
styles.d.ts
test-helpers.d.ts
vendors.d.ts

c:\test\14538\blaze-elements>yarn tsc
yarn tsc v0.18.1
$ "c:\test\14538\blaze-elements\node_modules\.bin\tsc"
Done in 4.48s.

@ BrainSlugs83, если у вас есть репро-проект, я бы с удовольствием посмотрел.

Я также столкнулся с той же проблемой, это ошибки:

А это мой tsconfig.json:

Поскольку я вообще не использую машинописный текст, я только что создал tsconfig, чтобы пропустить сборку, мне также пришлось выбрать target = ES6, иначе у меня были другие ошибки.

является ли tsconfig.json частью вашего проекта? и можете ли вы подтвердить, что тип контента - «Контент»? если да, то можете ли вы поделиться своим проектом?

@mhegazy Привет, да, я могу подтвердить, что tsconfig.json включен в проект:

Но мне очень жаль, что я не знаю, о каком «типе контента» вы говорите. Не могли бы вы уточнить?

Я не могу поделиться проектом.

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

@ max-favilli Я думаю, что @mhegazy означает «действие сборки», когда мы говорим о «типе содержимого».

Выберите tsconfig.json в обозревателе решений. Вызовите окно свойств (по умолчанию клавиша F4). Будет свойство Build Action.

Спасибо @kevindqc , @mhegazy да "Действие сборки" установлено на "содержание"

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

• перейдите к Tools > Options > Text Editor > TypeScript > Project и проверьте Display Virtual Projects when no Solution is loaded ;
• перезапустите VS и откройте файл в своем проекте
• теперь вы должны увидеть новый узел в обозревателе решений под именем TypeScript Virtual Project

@mhegazy нравится это?

Спасибо за помощь.

У меня точно такая же проблема. Я тоже не могу поделиться проектом, но постараюсь предоставить как можно больше информации.

У меня отключена компиляция машинописного текста в .csproj ( <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked> )
Вместо этого он компилируется npm run build:prod , который находится в событии сборки.

Ошибки есть не всегда. Я пытался заставить их появиться (они были показаны в VS, поэтому я перезапустил VS). Я пробовал создать проект машинописного текста, построить решение, запустить тесты, запустить анализ кода, запустить покрытие кода и т. Д. Ничто не запускает его. Затем, когда я писал последнее предложение, появились ошибки. Так вроде это какие-то фоновые задачи это делают? Кажется, это происходит примерно через 2 минуты после того, как я начал сборку (по крайней мере, 2-3 раза, когда я ее пробовал)

Лента новостей:
1:37:20 - Открыта Visual Studio
1:37:30 - Начат сборка решения
1:38:20 - Сборка завершена
1:39:39 - Появились ошибки

Я заметил, что мой проект все еще использует пакеты v2.0.3 Microsoft.TypeScript.Compiler и Microsoft.TypeScript.MSBuild nuget. Я обновил их до v2.2.1. Пока ошибок нет. Будет обновлено, если я снова увижу ошибки. (Изменить: я снова вижу ошибки, хотя это заняло немного больше времени, ~ 5 минут, и я ничего не делал, кроме построения, когда я открывал VS. На самом деле мне даже не нужно ничего создавать, чтобы получить ошибку - просто открываю проект и ожидание несколько минут показывает ошибки)

Насчет устаревших пакетов nuget, это нормально? Я думаю, что у меня появилось всплывающее окно для обновления инструментов машинописного текста моего проекта, когда я установил новую версию машинописного текста, но, похоже, он обновил только <TypeScriptToolsVersion>2.2</TypeScriptToolsVersion> . Не следует ли также обновлять пакеты nuget?

Я только что обновился до Typescript 2.2.1 и столкнулся с той же проблемой. Он отмечает все модули node_modules, но компилятор tsc завершает работу без проблем.

@mhegazy

@Hotell, я не вижу этого локально, что мне не хватает?

верно, это было исправлено https://github.com/wc-catalogue/blaze-elements/commit/cdb94bf8feb3a1ad7e21e6fce243e3322c1334cc

Извините за задержку с ответом и спасибо за помощь!

@Hotell @mhegazy У
Может это сработает, если у вас есть файлы d.ts в папке "определений"?
Но у меня этого нет. У меня есть @types в разделе "node_modules", которые должны быть исключены по наследству?

@chrismbarr Могу я спросить, решена ли эта слежу за этой @Hotell в нескольких сообщениях, но я все еще получаю эти ошибки в Visual Studios. Кажется, все они исходят из папки node_modules.

Сможете ли вы включить подробное ведение журнала и отправить нам результаты? Задайте для переменной системной среды TSS_LOG такое значение, как -file C:/temp/logs/tsserver.log -level verbose (убедитесь, что папка журналов существует). Затем, после воспроизведения проблемы, отправьте / прикрепите журнал для анализа. (Примечание: он может содержать такие данные, как пути к файлам и списки завершения, поэтому убедитесь, что в нем нет данных, которыми вы не хотите делиться).

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

Я могу предоставить свой адрес электронной почты, если вы предпочитаете отправлять файлы напрямую, а не загружать их (billti на microsoft dot com). Спасибо.

@johnlee нет, все то же самое в VS2015. Однако с тех пор я начал использовать Visual Studio 2017, и у меня нет ошибок!

Добавлена переменная

Это определенно переменная системной среды (например, если вы откроете новую командную строку и запустите SET TSS - это параметр, указанный в списке)? Если нет, то это папка, в которую должен быть записан журнал, уже существующий (регистратор не будет создавать каталоги, которые не существуют). Помимо этого, также безопаснее использовать в пути косую черту, а не обратную косую черту.

:(

@billti Хорошо, я только что проверил, и теперь файлы журнала там. Вы можете найти их здесь в приложении
tss-log.zip

Спасибо. Я просмотрел этот журнал и не заметил, чтобы какие-либо вызовы в нем сообщали об этой ошибке. Произошла ли ошибка в те временные рамки, которые указаны в этом журнале?

@billti Да, ошибки возникают постоянно:

Просто они там постоянно. И обновляется при каждой сборке.

Все эти ошибки связаны с неправильным объявлением переменных (отдельная проблема, которую мы уже исправили в следующем выпуске). Эта проблема касается Cannot write file... за заголовок и снимки экрана выше. У вас нет проблемы с Cannot write file... ?

@billti после публикации моего предыдущего сообщения (которое я оставил там в качестве демонстрации моей глупости) я понял, что это ошибки другого типа. Я могу только догадываться, что обновление Visual Studio, которое я установил несколько дней назад, решило исходную проблему. Но я не уверен.
Я избавился от этих ошибок из предыдущего сообщения, просто удалив типы из @types.
Большое спасибо.

@billti Я пытаюсь отправить вам журналы, но они не созданы. Я установил TSS_LOG в -file C:/temp/logs/tsserver.log -level verbose в своих системных (не пользовательских) переменных.

C:\temp\logs существует, и я передал полный контроль Everyone .

Если я перезапущу свой VS2015, внутри C:\temp\logs ничего не будет создано даже после того, как я получу все свои ошибки Cannot write file... . Если я попытаюсь ввести node node_modules\typescript\lib\tsserver.js (и сразу же CTRL + C) в новой командной строке, я получу два файла журнала.

Извините @kevindqc , я не знал, что вы используете VS 2015. Это ведение журнала применяется только к VS 2017 (который теперь использует tsserver.js вне процесса для языковой службы).

Вернемся и посмотрим на вашу проблему - если вы видите, что список ошибок меняется случайным образом, я считаю, что это та же проблема, которую @zhengbli только что исправил в https://github.com/Microsoft/TypeScript/pull/15080 .

@billti np. Я думаю, что эта проблема возникает только на VS2015, не так ли? Единственный пользователь с проблемой, который использовал VS2017, имел разные ошибки, связанные с вводом текста. Кто-то, кто переключился с VS2015 на VS2017, сказал, что проблема исчезла.

Кроме того, список ошибок не изменяется случайным образом - он заполняется в случайное время, один раз, всеми теми ошибками «Невозможно записать ..», о которых идет речь в этой проблеме. Вы уверены, что # 15080 это исправляет? Я ничего не вижу в этой проблеме, кроме той ссылки, которую вы сделали вчера? Как я могу это проверить? Я вижу, что есть версия 2.3 RC, но она была выпущена 9 дней назад, а исправление было объединено 2 дня назад :(

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

Кроме того, человек, разместивший свой виртуальный проект машинописного текста, был с разными ошибками, так что я полагаю, что это не помогло. Вот мой:

node_modules должен быть там? Это в моем tsconfig исключает. Он не содержит всего, что есть в моей физической папке node_modules (14 подпапок против 854 подпапок в моей папке node_modules)

{
  "compilerOptions": {
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "module": "commonjs",
    "moduleResolution": "node",
    "noImplicitAny": true,
    "removeComments": false,
    "sourceMap": true,
    "suppressImplicitAnyIndexErrors": true,
    "target": "es5",
    "baseUrl": "./src",
    "skipLibCheck": true,
    "paths": {
    },
    "typeRoots": [
      "node_modules/@types"
    ]
  },
  "exclude": [
    "node_modules",
    "dist",
    "typings"
  ],
  "types": [
    "core-js",
    "jasmine",
    "lodash",
    "node",
    "webpack"
  ],
  "awesomeTypescriptLoaderOptions": {
    "forkChecker": true,
    "useWebpackText": true
  }
}

После обновления до инструментов TS2.3 ошибок не было. Спасибо!
Изменить: Нет. В конце концов, ошибки все еще существуют, просто потребовалось больше времени, чтобы появиться.

Похоже, что эта проблема связана с этой проблемой . Образец решения для воспроизведения - загружен.

Я нашел для себя исправление. В моем случае я использовал outDir и rootDir без указания массива files . При добавлении пути outDir к массиву exclude все работает нормально.

{
    "compilerOptions": {
        ...,
        "outDir": "./dist",
        "rootDir": "./src",
    },
    "exclude": [
        "node_modules",
        "dist" <-- I had to add this to fix the errors
    ]
}

Возможно, TypeScript также следит за содержимым папки dist даже если она установлена ​​как outDir .

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

Похоже, все вышеперечисленные проблемы рассматриваются в этой теме или связанных проблемах. Дайте мне знать, если это не так, и я открою снова. Спасибо!

@billti Я предполагаю, что ваш комментарий является ответом на мой предыдущий комментарий? Если да, то спасибо за разъяснения. Теперь это делает вопрос для меня более очевидным, поскольку я предполагал, что при указании rootDir компилятор будет следить только за этой конкретной папкой и исключать все остальное. Но нынешнее поведение имеет смысл.

Лучшее решение - из борислемки .
{ "compilerOptions": { ..., "outDir": "./dist", "rootDir": "./src", }, "exclude": [ "node_modules", "dist" <-- I had to add this to fix the errors ] }

Я столкнулся с той же проблемой и обнаружил, что один из моих импортов неправильно ссылался на класс в моей папке dist EG
импортировать {ClassName} из "../../dist/ClassName";

Поскольку класс импорта находился в той же папке, я изменил его на:
импортировать {ClassName} из "./ClassName";

и все снова компилируется :)

В нашем приложении была предопределенная папка dist. Удаление этого исправило для меня.

Я думаю, что это основная проблема (последнее обновление Windows Creators Update):
Visual-Studio-2015-удаляет файл-при-сохранении-кордова-решение

Просто добавьте свою папку "dist" в список исключений в tsconfig.json.
бывший:
"exclude": ["node_modules", "dist"]

Я исправил это, добавив раздел "Включить":

"include": [ "*.ts", ], "exclude": [ "node_modules" ]

Я столкнулся с этим также при использовании outDir который находился в моем каталоге источников.

Как получается, что компилятор машинописного текста по умолчанию не знает, что он не должен пытаться скомпилировать вещи в outDir ? Это кажется странным. Однако добавление outdir в список исключений исправило это.

У меня проблема с netbeans, лол 👎

Я также получал эту ошибку, когда у меня было два файла foo.ts и foo.tsx , оба из которых, очевидно, компилируются в foo.js .

  "compilerOptions": {
    "noEmit": true 
  }

Исправил для меня.

noEmit является лучшим решением , если вы хотите сгенерировали *.js файлы , которые будут проанализированы. В конце концов, они не обязательно генерируются с помощью tsc .

В моем случае Ream.js генерирует .ream/**.js который я затем импортирую с import XXX from '#out/yyy' в свой код (который работает, но генерирует предупреждение «Невозможно записать файл ...» в VS Code).

По сути, единственная причина иметь "noEmit": false - это когда вы используете необработанные tsc . Для всех остальных сред ( ts-node / ts-node-dev , webpack, rollup) безопаснее включить его.

Как и @uglycoyote, у меня сработало добавление outdir в массив исключений. Ни одно из других предложений не сработало.

Я чувствую, что эта проблема связана с этим:

• https://github.com/TypeStrong/ts-node/issues/270
• https://github.com/Microsoft/TypeScript/issues/9858
• https://github.com/Microsoft/TypeScript/issues/11299

Проблема возникает из-за того, что я установил "declaration": true в tsconfig.json , поэтому он сердится на файлы d.ts в папке сборки, даже если каталог находится за пределами корень. Я могу сделать новую сборку без проблем, но любая последующая сборка выдаст: Cannot write file ... because it would overwrite input file. . Из того, что я мог видеть в других историях, раньше это работало в другой версии, значит, что-то, должно быть, изменилось.

Так же, как я исправил проблемы с моими test.ts файлами, находящимися за пределами rootDir мне пришлось добавить следующее к tsconfig.json .

"exclude:" [ "./build" ]

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

{
  "extends": "../../base/tsconfig.json",
  "compilerOptions": {
    "outDir": "myOutDir"  // <--- Don't forget this
  }
}

Также стоит проверить, нет ли у вас ошибочной ссылки в package.json на "outDir"

"main": "lib/index.js",
  "typings": "lib/__types__",      <-------
  "devDependencies": {
    "@types/lodash.mapvalues": "^4.6.4",
    "@types/node": "^10.12.18",
    "@types/winston": "^2.4.4"
  }

Я испытал это в проекте со ссылками на проекты. Ни одно из исключений не имело значения, что имело значение, так это запись typings намекнул @elmpp.

Таким образом, это приведет к TS5055: Cannot write file because it would overwrite input file в монорепозитории ссылок на проект:

  "main": "lib/cjs/index.js",
  "module": "lib/esm/index.js",
  "typings": "lib/cjs/index.ts",

но это не сообщит об ошибках:

  "main": "lib/cjs/index.js",
  "module": "lib/esm/index.js",
  "typings": "src/index.ts",

Так что, очевидно, мне нужно будет либо изменить эту предварительную публикацию, либо опубликовать src в пакете.

Параметр:

"exclude": [
    "node_modules",
    "dist"
  ]

исправил это для меня (мой outputDir был dist ).

Было бы здорово, если бы выходной каталог по умолчанию был исключен для tsc --watch .

Для справки в будущем это произойдет, если вы импортируете модуль из самого себя.

Таким образом, выполнение import x from 'mymodule внутри mymodule вызовет это. Это очень загадочно и, вероятно, следует исправить!

Точно так же я столкнулся с проблемой, если у вас есть index.ts с кучей строк, таких как export * from './foo' , и в одном из этих файлов я импортировал с помощью import foo from '.' а не import foo from './foo' в одном из этих экспортированных файлов.

Я бился об этом последние два дня, пока не удалил index.ts и не получил ошибку импорта. Это было очень неочевидно.

Поэтому я думаю, что проблема заключалась в том, что у меня есть 2 проекта ts в одном репо. (Angular и Nestjs), tsconfig.json папки уровня 1 выдает эту ошибку. Я исправил это, поставив exclude «public», который публично является моими кодами Angular с собственным tsconfig.json.

У меня была эта проблема, потому что я не был уверен, почему ts-node не работает, тогда я tsc чтобы проверить, была ли проблема TypeScript. В результате tsc меня теперь были десятки файлов .js рядом с ts которые я мог подтвердить, запустив git status

Решение было git clean -f .

В моем случае кажется, что VS Code автоматически импортировал файл из папки dist а не из папки src . Исправление решило проблему.

Это действительно не должно быть закрыто, машинописный текст должен выводить ошибку, сообщающую вам, что происходит. В настоящее время это практически невозможно выяснить. Я не уверен, что вызывает это так часто, VSCode может случайно обновлять ссылки tsconfig.json, но это замедляет все на тонну, и каждый раз было нетривиальным для отладки.

в проекте Vue в корне это сработало для меня:

// tsconfig.json
{
    "include": ["./src/**/*"],
    "exclude": ["node_modules", "dist", "public"],
    "compilerOptions": {
      "module": "es2015",
      "outDir": "",
      "moduleResolution": "node",
      "target": "es5",
      "allowJs": true,
      "checkJs": true, // Type checking
    }
}

После того, как я добавил
"outDir": "",
проблема исчезла.

Моя цель - заставить ts intellisence работать в файлах .js / vue.

Было такое же сообщение об ошибке. Проблема заключалась в том, что у меня было два файла с одинаковым именем, но с разными расширениями в одной папке, поэтому удаление файла с расширением .js исправило это.

Было такое же сообщение об ошибке. Проблема заключалась в том, что у меня было два файла с одинаковым именем, но с разными расширениями в одной папке, поэтому удаление файла с расширением .js исправило это.

Да, у меня была такая же проблема. Я переименовал файл .tsx .ts который VS-Code был услужливо воссоздан, что вызвало проблему.

Не уверен, как правильно решить эту проблему, но в моем случае я просто удалил "declaration": true из tsconfig.json. Файлы D.ts не создаются, но они мне все равно не нужны.

Разрешите мне поделиться своими выводами для всех, кто пришел сюда через поиск в Google аналогичного сообщения об ошибке:

1. Как вы можете прочитать, эта ошибка была вызвана тем, что компилятор TypeScript пытался скомпилировать файл .js по тому же пути.
2. Скорее всего, вы вообще не хотите компилировать файлы .js. Если возможно, удалите allowJs: true из tsconfig.json или --allow-js из параметров интерфейса командной строки.
3. Если они вам определенно нужны, вы можете исключить файлы, упомянутые в сообщении об ошибке, из компиляции. Некоторые люди в этой ветке сделали это (возможно, не заметив), добавив exclude: ... .
   
   
   
   • Будьте осторожны и не добавляйте «исключить» под compilerOptions .
   
   

Надеюсь, это поможет 🙏

Мне нужно было вручную исключить каталог сборки lib/

Кажется, где-то есть ошибка, из-за которой некоторые параметры несовместимы. Я узнал, что с помощью
allowJS true +
rootDir + outDir : ОК
rootDir + outFile : NOK: rootDir не учитывается: все файлы в каталоге dir и subdir настроены на компиляцию и потенциально перезаписываются.
некоторые другие комбинации опций запрещены.

"allowJs": true
"noEmit": true
работать на меня.

в проекте Vue в корне это сработало для меня:

// tsconfig.json
{
    "include": ["./src/**/*"],
    "exclude": ["node_modules", "dist", "public"],
    "compilerOptions": {
      "module": "es2015",
      "outDir": "",
      "moduleResolution": "node",
      "target": "es5",
      "allowJs": true,
      "checkJs": true, // Type checking
    }
}

После того, как я добавил
"outDir": "",
проблема исчезла.

Моя цель - заставить ts intellisence работать в файлах .js / vue.

спасибо, у меня работает.

Если вы используете TS ТОЛЬКО для .js , используйте решение @ guaizi149 :

"compilerOptions": {
  "allowJS": true,
  "noEmit": true
}

Это скажет TS, что он не должен беспокоиться о компиляции, поэтому ни один файл не будет перезаписан, и не будет срабатывать никаких предупреждений. Это лучшее решение для использования outDir: "" .

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

{
  "extends": "../../base/tsconfig.json",
  "compilerOptions": {
    "outDir": "myOutDir"  // <--- Don't forget this
  }
}

Это решение сработало для меня как шарм! Мои tsconfig.json теперь выглядят так:

{
  "compilerOptions": {
    "allowJs": true,
    "baseUrl": "../node_modules",
    "types": ["cypress"],
    "outDir": "myOutDir"
  },
  "include": ["**/*.*"]
}

"allowJs": true
"noEmit": true
работать на меня.

Спасибо @ guaizi149 , ваше решение у меня работает 👍

Решено - я включил каталог dist в мою сборку tsc:

"exclude": [
    "node_modules"
  ]

--- идет к

"exclude": [
    "node_modules",
    "dist"
  ]

dist ваша папка сборки?

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

Это происходит, когда файлы объявлений не исключаются из сборки. Каждый раз, когда это происходит, построитель пытается собрать существующие файлы «.d.ts» и заменить их с тем же именем файла. Вот почему вы получите ошибку: Cannot write file ... because it would overwrite input file.

Чтобы предотвратить это, вы можете исключить свой "outDir":"build" в файле jour tsconfig.json:

"exclude": [
    "build",
    ....
]

или если у вас не определен outDir, исключить все d.ts . файлы расширения:

"exclude": [
    "**/*.d.ts"
    .....
]

Надеюсь это поможет

@Abadii : возможно, это потому, что я использую параметр -b при компиляции, но ни один из этих подходов не сработал.

@Abadii : возможно, это потому, что я использую параметр -b при компиляции, но ни один из этих подходов не сработал.

Можете ли вы поделиться своим файлом tsconfig.json и какой версии у вас tsc ?

@Abadii : Вот он (очевидно, без обновленного исключения). Версия tsc - 3.8.3:

{
    "compilerOptions": {
        "importHelpers": true,
        "target": "es6",
        "module": "CommonJS",
        "lib": ["es2018"],
        "downlevelIteration": true,
        "skipLibCheck": true,
        "strict": true,
        "moduleResolution": "node",
        "esModuleInterop": true,
        "experimentalDecorators": true,
        "outDir": "../lib",
        "sourceMap": true,
        "declaration": true
    },
    "exclude": ["node_modules"]
}

@Abadii : Вот он (очевидно, без обновленного исключения). Версия tsc - 3.8.3:

{
    "compilerOptions": {
        "importHelpers": true,
        "target": "es6",
        "module": "CommonJS",
        "lib": ["es2018"],
        "downlevelIteration": true,
        "skipLibCheck": true,
        "strict": true,
        "moduleResolution": "node",
        "esModuleInterop": true,
        "experimentalDecorators": true,
        "outDir": "../lib",
        "sourceMap": true,
        "declaration": true
    },
    "exclude": ["node_modules"]
}

Взгляните на следующее репо. Я использовал ваш tsconfig.json, чтобы восстановить ошибку:

https://github.com/Abadii/tsconfig

PS А что будет при удалении папки ../lib? Будет ли оно построено?

@Abadii : он будет построен, если я удалю папку сборки (на самом деле он будет построен только в том случае, если я удалю / очищу папку сборки). Это верно, даже если я exclude файлы декларации и папка сборки.
К вашему сведению, структура проекта такая:

project\
  lib\
    session.d.ts
    session.js
  src\
    session.ts
    tsconfig.json
  package.json 

и я строю с помощью: tsc -p ./src/tsconfig.json
(на самом деле обычно я строю с помощью rm -rf ./lib && tsc -p src/tsconfig.json но это то, что я здесь, чтобы исправить;))

@Abadii : он будет построен, если я удалю папку сборки (на самом деле он будет построен только в том случае, если я удалю / очищу папку сборки). Это верно, даже если я exclude файлы декларации и папка сборки.

Итак, теперь вы знаете, что проблема возникает из-за папки сборки. Каким-то образом ваша сборка tsc не исключает вашу папку сборки. Вы можете попробовать использовать абсолютный путь в исключении.
Я также заметил, что ваша папка сборки выходит за пределы вашей области действия ../lib . Может быть, это также причина, по которой он не исключает. Попробуйте ./lib как outDir, чтобы проверить, не меняет ли он поведение
Если вы пользователь Windows, дважды проверьте правильность указанного абсолютного пути.

@Abadii : Спасибо, но я не могу использовать абсолютные пути, так как работаю над проектом на нескольких машинах и не могу гарантировать одинаковую структуру папок на всех из них. Мне это кажется ошибкой - я говорю tsconfig исключить и папку, и файлы декларации, но это не так. Следует ли его снова открыть?

@Abadii : Спасибо, но я не могу использовать абсолютные пути, так как работаю над проектом на нескольких машинах и не могу гарантировать одинаковую структуру папок на всех из них. Мне это кажется ошибкой - я говорю tsconfig исключить и папку, и файлы декларации, но это не так. Следует ли его снова открыть?

Я понимаю, может быть, последнее, что вы можете попробовать, - это поместить свой файл tsconfig в project/tsconfig.json и изменить пути. У меня также нет вариантов, если это не сработает, я думаю.

Пытался:

1. Установка outDir -> нет.
2. Установка allowJs: false -> нет.
3. Исключая .d.ts -> нет.
4. noEmit: true -> нет.

Я пробовал все предложения в этой теме. Ошибка VSCode не только сохраняется, но и относится к файлу, который больше не существует. 🤷‍♂️

Пытался:

1. Установка outDir -> нет.
2. Установка allowJs: false -> нет.
3. Исключая .d.ts -> нет.
4. noEmit: true -> нет.

Я пробовал все предложения в этой теме. Ошибка VSCode не только сохраняется, но и относится к файлу, который больше не существует.

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

Установите outDir и обязательно сделайте его пустым перед построением

@Abadii Итак .... похоже, что это произошло потому, что, хотя файлы JS не были включены, они не работали, потому что они были модулями CommonJS .... 🤔 ....

Другими словами, как только все было правильно импортировано / экспортировано, я перестал получать эту проблему. Итак, основываясь на комментариях к этой ветке и огромном количестве исправлений, я думаю, что это одна из тех отвлекающих ошибок. Например, когда возникает проблема JS / Intellisense / компиляции типа X, VSCode выдает эту ошибку Cannot write file . Но в моем случае это было решено с помощью решения, ДРУГОГО, чем любое другое из многочисленных решений, предлагаемых в этом потоке. 🤷‍♂️ И снова эта ошибка возникла в файле, который _не существует_ и _ не может быть заменен_. Так может быть, ошибки кешируются, а неизвестная ошибка вызывает кешированную ошибку? Что-то подобное? Я думаю, что кому-то нужно проверить код именно этой ошибки.

Комментирую здесь, потому что это первое, что появилось в моем поиске в Google.

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

Я не вижу проблемы, если сделаю так:

  "exclude": ["**/*.d.ts", "dist", "node_modules"]

Я действительно вижу проблему, если сделаю это:

  "exclude": ["dist/**/*.d.ts", "dist", "node_modules"]

или это:

  "exclude": ["**/dist/**/*.d.ts", "dist", "node_modules"]

Ошибка возникает, несмотря на то, что файлы, на которые она жалуется, явно находятся внутри dist :

error TS5055: Cannot write file '/Users/leila/dev/wip/jest-fp-ts/dist/index.d.ts' because it would overwrite input file.
error TS5055: Cannot write file '/Users/leila/dev/wip/jest-fp-ts/dist/matchers/index.d.ts' because it would overwrite input file.

В моем случае у меня настроен импорт, где src/index.ts импортирует и реэкспортирует из src/matchers/index.ts который, в свою очередь, импортирует и реэкспорт из src/matchers/eitherMatchers/index.ts .

Первые два файла вызывают ошибки компиляции. Третий файл в порядке. Похоже, это может быть связано с тем, как дерево импорта / экспорта влияет на компиляцию.

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

В моем случае у меня есть монорепозиторий с отдельным файлом tsconfig для каждого пакета, который все наследует от базового tsconfig. В каждой конфигурации пакетов есть записи references которые указывают путь к пакетам, от которых она зависит. У меня также есть tsconfig.json в корне репо, который включает files: [] и имеет ссылки на все каталоги пакетов. Таким образом, я могу запустить tsc -b --watch из корня и восстановить его при изменениях на протяжении всего проекта.

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

Я наконец отследил это, попытавшись собрать один пакет, о котором сообщалось в ошибке, вместо того, чтобы строить весь проект.

Оказывается, проблема заключалась в том, что я пытался импортировать сам проект. Имя пакета было @my-project/utils , и он работал нормально, пока я не переместил код из другого пакета в файл в пакете utils. Этот код включал import stuff from '@my-project/utils'; и это было причиной ошибки. При изменении на import stuff from '.'; ошибка исчезла ..

@jasonk Это, вероятно, просто свидетельствует о моем невежестве, но разве это не сработает только в том случае, если ваш монорепозиторий объединен чем-то, что разрешит весь этот импорт (например, веб-пакет)? Если ваш монорепозиторий состоит из модулей, которые можно публиковать и использовать независимо, переход на относительный импорт вызовет ошибки, нет?

@Ghirigoro Нет, проблема не в том, что я использовал путь к пакету, а в том, что он использовал путь к пакету для импорта пакета из самого себя. Даже без машинописного текста это не сработает.

По сути, то, что я сделал, было эквивалентом этого:

$ mkdir problem
$ cd problem
$ npm init -y
$ echo 'console.log( "WORKED!" );' > index.js
$ echo 'require( "problem" );' > test.js

Если вы затем попытаетесь запустить это с помощью узла:

$ node ./test.js
internal/modules/cjs/loader.js:985
  throw err;
  ^

Error: Cannot find module '/Users/jasonk/problem/test.js'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:982:15)
    at Function.Module._load (internal/modules/cjs/loader.js:864:27)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:74:12)
    at internal/main/run_main_module.js:18:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

Если вы замените имя пакета, он работает правильно:

$ echo 'require( "." );' > test.js
$ node ./test.js
WORKED!

Я подозреваю, что произошло следующее: когда сборка была запущена, все остальные пакеты, которые импортировались из @my-project/utils , разрешили этот импорт в packages/utils (потому что у них были правильные записи в references array в tsconfig), поэтому они строились нормально. Но поскольку этот пакет не должен был импортировать сам себя, этот импорт был разрешен до node_modules/@my-project/utils , что являлось символической ссылкой на packages/utils , но TypeScript не обнаружил, что они на самом деле были одним и тем же проектом, поэтому он пытался создать его дважды, но поскольку обе сборки имели один и тот же выходной каталог, я получил эту ошибку.

Это происходит, когда файлы объявлений не исключаются из сборки. Каждый раз, когда это происходит, построитель пытается собрать существующие файлы «.d.ts» и заменить их с тем же именем файла. Вот почему вы получите ошибку: Cannot write file ... because it would overwrite input file.

Чтобы предотвратить это, вы можете исключить свой "outDir":"build" в файле jour tsconfig.json:

"exclude": [
    "build",
    ....
]

или если у вас не определен outDir, исключить все d.ts . файлы расширения:

"exclude": [
    "**/*.d.ts"
    .....
]

Надеюсь это поможет

Исключение моего каталога сборки решило проблему для меня

Скорее всего, это происходит, когда вы пытаетесь запустить один проект с двумя узлами.
Для этой гипотезы вы можете проверить количество процессов на вашем компьютере с именем «узел» после запуска сборки.
Что я сделал для решения проблемы:
Шаг 1.
Сравнивать
node -v
а также
nvm -ls , используемая версия.
В терминале установить текущую версию узла:
nvm use {neededVersion}
В принципе, удалите ненужные версии узла в nvm (это поможет вашей IDE автоматически определить нормальную версию узла).
Шаг 2.
Определите текущий узел в вашей IDE. т.е. в WebStorm:
Предпочтения-> Языки и фреймворки -> Node.js и NPM: интерпретатор узла - установите нужную версию.
(Кроме того, вы можете везде проверить версию узла для каждого элемента (Typescript))

Кроме того, эта проблема может возникнуть, если пакеты npm или подмодули git использовали свой собственный узел внутри

Я столкнулся с этой проблемой для проекта Webdriver IO / WDIO. Это было решено, когда я удалил "wdio.config.js" из "include" в tsconfig.json.