Typescript: tsc не должен заботиться и терпеть неудачу с файлами ts вне rootDir

Чтобы обойти, я добавляю "исключить" обратно в свой tsconfig.json

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

@mhegazy Спасибо за разъяснения. По имени rootDir я взял его как корневой каталог исходного кода, что очень похоже на baseURL для браузера. Не знал, что это только для структуры выходной папки.

Вот мой tsconfig.json:

{
    "compilerOptions": {
        "target": "es5",
        "module": "commonjs",
        "moduleResolution": "node",
        "sourceMap": true,
        "emitDecoratorMetadata": true,
        "experimentalDecorators": true,
        "removeComments": true,
        "noImplicitAny": true,
        "rootDir": "src",
        "outDir": "build"
    },
    "exclude": [
        ".idea",
        "build",
        "node_modules",
        "typings/globals",
        "typings/modules"
    ]
}

Моя структура папок выглядит так:

• проект
  
  
  
  • строить
  
  
  • node_modules (символическая ссылка на ../node_modules)
  
  
  • node_modules
  
  
  • src
  
  

Я хочу, чтобы мои файлы .ts в папке src были скомпилированы и выводились с той же структурой папок в папку сборки. Я делаю это для того, чтобы установить корень моего документа в папку сборки и сохранить свой src вне корня документа. Я получаю сообщения об ошибках для файлов .ts в папке node_modules, те же сообщения об ошибках, что и OP. Обратите внимание, что у меня исключены node_modules. Почему tsc жалуется на это?

@HillTravis, похоже, ваша проблема такая же, как https://github.com/Microsoft/TypeScript/issues/9552.

@mhegazy Я не уверен, что это то же самое. Да, моя структура включает символическую ссылку, но любое место, где существует эта символическая ссылка, следует игнорировать.

В # 9552 нет папки src, то есть папка node_modules существует по пути, который создается. В моем сценарии корневой каталог, на который должен смотреть tsc, - это src, который не содержит node_modules. Так что он вообще не должен смотреть на эту папку. Вдобавок ко всему, у меня есть папка node_modules, явно исключенная через мой tsconfig.json. Так что это следует игнорировать вдвойне. У меня также исключена папка build , которая должна охватывать символическую ссылку на node_modules внутри нее.

Также в # 9552 не было упоминания об ошибках или неудачной компиляции.

Я также должен упомянуть, что использую TypeScript 1.8.10.

В частности, сообщения об ошибках гласят:

ошибка TS6059: файл '/Users/thill/Projects/nrc/client/node_modules/ng2-datetime/src/ng2-datetime/ng2-datetime.module.ts' не находится в 'rootDir' '/ Users / thill / Projects / nrc / клиент / src '. Предполагается, что rootDir будет содержать все исходные файлы.

ошибка TS6059: файл '/Users/thill/Projects/nrc/client/node_modules/ng2-datetime/src/ng2-datetime/ng2-datetime.ts' не находится в 'rootDir' / Users / thill / Projects / nrc / клиент / src '. Предполагается, что rootDir будет содержать все исходные файлы.

ошибка TS6059: файл '/Users/thill/Projects/nrc/client/node_modules/ng2-datetime/src/ng2-datetime/timepicker-event-interface.ts' не находится в 'rootDir' '/ Users / thill / Projects / nrc / клиент / src '. Предполагается, что rootDir будет содержать все исходные файлы.

@HillTravis, вы можете мне

В качестве теста я попытался удалить символическую ссылку. Собственно, я удалил всю папку build . Затем я снова запустил tsc и все еще увидел ошибку.

Во время дополнительного тестирования я попытался закомментировать импорт в коде и использование этого конкретного модуля узла (ng2-datetime), и ошибка исчезла. Таким образом, только когда я пытаюсь импортировать этот модуль узла, я вижу ошибку, независимо от символической ссылки.

Если вы посмотрите на исходный код этого пакета на GitHub, вы увидите, что в файле package.json для параметра «main» задано значение «ng2-datetime.js», хотя автор также опубликовал файл .ts с тем же имя. Похоже, это вызывает проблему. Если я создам файлы .d.ts и удалю файлы .ts, проблема исчезнет. Он компилировался без проблем даже после добавления символической ссылки.

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

Вы знаете, есть ли какое-нибудь решение для этого? OP выше сказал, что обошел это, добавив "исключить" обратно в tsconfig.json. У меня уже есть исключенный каталог, но он все еще пытается его скомпилировать.

Вы знаете, есть ли какое-нибудь решение для этого? OP выше сказал, что обошел это, добавив "исключить" обратно в tsconfig.json. У меня уже есть исключенный каталог, но он все еще пытается его скомпилировать.

Это может быть связано с другим, но я не могу найти его прямо сейчас. При разрешении типа tsc всегда пытается найти его из node_modules , пока его там нет (связано с typings ).

«tsc не должен заботиться о файлах ts вне rootDir и отказываться от них» Я согласен.

Я не могу понять, почему машинописный текст будет искать файлы JS вне rootDir, поскольку именно там должен быть весь исходный код.
В сообщении об ошибке говорится: «Ожидается, что 'rootDir' будет содержать все исходные файлы», тогда ничего вне этого каталога не следует ожидать или считать исходным файлом, что касается TS!

Если это «Работа по задумке», то в чем именно заключается намерение или мотивация такого поведения? Есть ли случай, когда TS захочет скомпилировать исходные файлы, расположенные за пределами rootDir?

С другой стороны, добавление раздела "include" в tsconfig решает проблему. При наличии файлов или каталогов для включения TS не просматривает другие файлы за пределами этого.

с машинописным текстом 1.8.10

У меня была папка node_modules в моем домашнем каталоге ~/node_modules . Запуск tsc из моего проекта dir ~/projects/myProject/ привел к тому, что машинописный текст пожаловался на следующие файлы

../../node_modules/aws-sdk/index.d.ts(7,1): error TS1128: Declaration or statement expected.
../../node_modules/aws-sdk/index.d.ts(7,11): error TS1005: ';' expected.
../../node_modules/aws-sdk/index.d.ts(7,24): error TS1005: '{' expected.
../../node_modules/aws-sdk/lib/config.d.ts(1,1): error TS1084: Invalid 'reference' directive syntax.
../../node_modules/aws-sdk/lib/config.d.ts(29,84): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(36,62): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(68,133): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(75,111): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/request.d.ts(1,1): error TS1084: Invalid 'reference' directive syntax.
../../node_modules/aws-sdk/lib/services/glacier.d.ts(1,1): error TS1084: Invalid 'reference' directive syntax.

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

@iwllyu, можешь ли ты проверить свой проект на [email protected] и сообщить о новой проблеме, если проблема не исчезнет.

Все еще есть проблема с 2.1.4, хотя она жалуется на другой набор файлов

Using tsc v1.8.10
../../node_modules/aws-sdk/index.d.ts(7,1): error TS1128: Declaration or statement expected.
../../node_modules/aws-sdk/index.d.ts(7,11): error TS1005: ';' expected.
../../node_modules/aws-sdk/index.d.ts(7,24): error TS1005: '{' expected.
../../node_modules/aws-sdk/lib/config.d.ts(27,84): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(34,62): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(66,133): error TS1110: Type expected.
../../node_modules/aws-sdk/lib/config.d.ts(73,111): error TS1110: Type expected.

Using tsc v2.1.4
../../node_modules/aws-sdk/lib/config.d.ts(38,37): error TS2304: Cannot find name 'Promise'.
../../node_modules/aws-sdk/lib/request.d.ts(164,16): error TS2304: Cannot find name 'Promise'.
../../node_modules/aws-sdk/lib/s3/managed_upload.d.ts(15,16): error TS2304: Cannot find name 'Promise'.

Я создам проект, чтобы изолировать тестовый пример

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

Об этом деле. Если все, что вы импортируете, - это типы (например, я действительно просматриваю эту волну «передний машинописный текст, задний машинописный текст») извне - может быть, tsc сможет различить то, что я делаю?
Я передаю только типы своих сущностей из серверной части в мое внешнее приложение. Вывод, конечно, без типов и импорта этих классов (потому что они используются только для времени компиляции и intellisense).

Было это тоже.
Машинопись слишком ограничивает нашу команду - учитывая поток сейчас.

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

какой вариант лучше? копировать-вставить туда и сюда и изменить, если я изменю типы?

создание одного корневого каталога для двух проектов не вариант, так как бэкэнд tsconfig.json будет иметь информацию о jsx и компилироваться в commonjs, когда я могу использовать es2015

Вам подходит baseUrl ?

@unional не изменяет baseUrl, нарушает весь импорт node_modules - не требуется писать

import * as request from "superagent";

но

import * as request from "node_modules/superagent/..something";

?

Блех, это действительно работает как задумано? Я просто столкнулся с этим, я сказал машинописному тексту, что мой источник находится в определенной папке (через rootDir ), а затем он начал _полностью игнорировать то, что я ему сказал_, потому что у меня был один файл с .ts Расширение

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

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

{
    "compilerOptions": {
        "outDir": "./output",
        "rootDir": "./source",
    },
    "include": [
        "source"
    ]
}

Я сказал машинописному тексту, что мой источник находится в определенной папке (через rootDir)

Это не то, что означает rootDir ! rootDir означает «Используйте эту папку как относительную основу для вычисления путей в outDir ». Какие файлы являются частью вашей компиляции - это отдельный вопрос, на который отвечает files и / или include / exclude

Даже если я согласен с этим, текущее поведение все еще является ошибкой IMO. Если у меня есть какие-либо файлы TS вне указанного каталога, тогда rootDir _не_ будет основой для вычисления путей в outDir , то есть указанная мной конфигурация будет полностью проигнорирована.

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

Пример сообщения об ошибке, которое было бы гораздо более понятным (вместе с серьезным отказом):

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

Примечание. Большая часть причины, по которой текущее поведение rootDir кажется очень неправильным, заключается именно в том, что не имеет смысла иметь файлы вне rootDir. Когда кто-то спрашивает себя (или компилятор), что значит компилировать файлы вне rootDir единственный ответ - «это не имеет смысла». Таким образом, можно сделать естественный вывод, что rootDir также определяет sourceDir.

Зло в именовании. На самом деле это означает relativePathBaseDir или что-то в этом роде.

Я также заметил, что include обычно означает «смотрите и сюда», но в данном случае это означает «только смотрите сюда».
Было бы разумно, чтобы он имел другое имя и был обязательным.

ИМО, этот комментарий следует особенно принять во внимание, чтобы подтвердить, что это действительно ошибка и ее следует повторно открыть как таковую:

Примечание. Большая часть причины, по которой текущее поведение rootDir кажется очень неправильным, заключается именно в том, что не имеет смысла иметь файлы вне rootDir. Когда кто-то спрашивает себя (или компилятор), что значит компилировать файлы вне rootDir единственный ответ - «это не имеет смысла».

Действительно, в этом нет смысла . «Исходные файлы за пределами rootDir » просто не являются исходными файлами , независимо от их расширения или содержимого. Компилятор никогда их не скомпилирует. Так почему он жалуется на их существование? Он ревнует, что есть файлы, не подчиняющиеся его правлению?

+100 за то, что это ошибка (на самом деле неприятная). Рассмотрим следующую структуру каталогов:

- src/
  - module.ts
- test/
  - module.test.ts
- out/
  - module.js

Я бы хотел, чтобы tsc компилировал только src , потому что я запускаю тесты с ts-node . Наличие rootDir: 'src' настоящее время вызовет ошибку компиляции. Если вы помечаете тесты и другие вещи, которые вы собираетесь выполнять только с помощью ts-node (или даже, возможно, компилировать отдельно?), Как «исключенные», тогда начнут происходить плохие вещи (например, выделение vscode перестает работать в тестах )

Фактически, никакая комбинация rootDir , excluded и всех других параметров не удовлетворяет всем требованиям (исключить тесты из компиляции, но при этом иметь возможность запускать их и работать с ними).

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

Настройка src / test / out была ключевым сценарием, рассмотренным в ссылках на проекты.

Я обнаружил эту проблему, потому что искал в Google, почему typescript пытался скомпилировать мой файл webpack.config.js после того, как я установил rootDir .

Я сказал машинописному тексту, что мой источник находится в определенной папке (через rootDir)

Это не то, что означает rootDir! rootDir означает «Использовать эту папку как относительную основу для вычисления путей в outDir». Какие файлы являются частью вашей компиляции - это отдельный вопрос, на который отвечают файлы и / или включают / исключают

Это ответ! Документы для rootDir говорят

Задает корневой каталог входных файлов

Я понял, что это означает "входные _ исходные_ файлы". Я рекомендую, чтобы комментарий

Ссылка здесь - https://github.com/Microsoft/TypeScript/issues/11299 является дубликатом этой проблемы. (Решение: используйте include / exclude, чтобы указать файлы для компиляции, rootDir НЕ указывает, какие файлы нужно компилировать.)

@mhegazy Не

Я тоже столкнулся с этой проблемой и не смог ее решить.

Компиляция tsc перемещает дерево из моего включенного каталога в родительские папки, вызывая ошибки повторяющегося типа.

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

└─src
└─package.json
└─node_modules
└─tsconfig.json
└─example
│ └─src
│ └─package.json
│ └─node_modules
│ └─tsconfig.json

Теперь, когда я пытаюсь запустить tsc из каталога с примерами, я получаю следующую ошибку:

node_modules/@types/react/index.d.ts:2809:14 - error TS2300: Duplicate identifier 'LibraryManagedAttributes'.

2809         type LibraryManagedAttributes<C, P> = C extends React.MemoExoticComponent<infer T> | React.LazyExoticComponent<infer T>
                  ~~~~~~~~~~~~~~~~~~~~~~~~

  ../node_modules/@types/react/index.d.ts:2814:14
    2814         type LibraryManagedAttributes<C, P> = C extends React.MemoExoticComponent<infer T> | React.LazyExoticComponent<infer T>
                      ~~~~~~~~~~~~~~~~~~~~~~~~
    'LibraryManagedAttributes' was also declared here.

Как видно из ошибки, tsc проходит дерево вверх и выходит из папки примера и просматривает папку node_modules родительского каталога! Что еще хуже, так это то, что я попытался явно игнорировать родительский каталог node_modules с небольшим эффектом.

Вот tsconfig примера директории:

{
  "compilerOptions": {
    "target": "es5",
    "experimentalDecorators": true,
    "module": "commonjs",
    "sourceMap": true,
    "outDir": "./dist",
    "rootDir": "./src",
    "strict": true,
    "moduleResolution": "node",
    "lib": ["es2017", "dom"],
    "jsx": "react"
  }
,
  "typeRoots": [
    "./node_modules/@types"
  ],
  "include": [
    "src"
  ],
  "exclude": [
    "node_modules",
    "../node_modules"
  ]
}

Как я могу решить эту проблему? Мне кажется, что ничего из вышеперечисленного не работает.

@lexwebb У меня была такая же проблема, проверьте свои yarn.lock файлы, что @types/react имеют одинаковые версии.
См. Https://stackoverflow.com/questions/52399839/typescript-duplicate-identifier-librarymanagedattributes.

Я приземлился здесь, потому что моя папка с ресурсами содержит видеофайл «MPEG Transport Stream» с расширением .ts поэтому tsc вылетает, даже если папки не было в моем пути rootDir 😄

Я исправил это, добавив папку с ресурсами в пути exclude но это было неприятным поведением 🤔

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

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

По моему личному опыту, причина, по которой сборка машинописного текста выходит за пределы вашего дерева rootDir и пытается создать то, чего вы не ожидаете, заключается в том, что вы (намеренно или случайно) прямо или косвенно ссылались на что-то в этом область из вашего rootDir . Если вы это сделаете, то сборка будет следовать дереву ссылок независимо от того, пытались ли вы исключить область, содержащую указанный файл. Иногда PITA пытается выяснить, как / где вы это сделали, но всегда я обнаруживаю, что это моя собственная ошибка, а не ошибка tsc . Он просто выполняет то, что я ему сказал.

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

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

@kpturner Звучит супер разумно, но - тестовый проект barebones без импорта между папками будет производить поведение, на которое все жалуются.

Действительно? Этого я никогда не видел :)

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

Есть ли в этой теме простые примеры? Трудно сказать по телефону.

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

т.е. компиляция чего-то подобного приведет к ошибке.

-src / src.ts <- no imports -test / test.ts -out -tsconfig.json {"rootDir": "src", "outDir": "out"}

Но если ваш tsconfig.json выглядит так, я ожидаю, что машинописный текст скомпилирует все в каталоге src и все в каталоге test . Если вы хотите, чтобы он переносил только вещи из src и выводил их в каталог out тогда ваш tsconfig.json должен быть

{
    "compilerOptions": {
        "rootDir": "src",
        "outDir": "out"
    }
}

Тогда это вызовет ошибку TS6059, потому что у вас есть файлы за пределами rootDir . Итак, вам нужно исключить те:

{
    "compilerOptions": {
        "rootDir": "src",
        "outDir": "out"
    },
    "exclude": [
        "test"
    ]
}

который при переносе сгенерирует папку с именем out с подпапкой src содержащей src.js . Папка test полностью игнорируется. Это то, что я ожидал, - нет?

Э, действительно, мой пример tsconfig должен был включать rootDir и outDir под compilerOptions как вы показываете в своем первом примере. Вы также правы, что при исключении test исключаются test и его файлы. Первоначально я думал, что вы говорите, что (или) виновником ошибки TS6059 является файл в rootDir импортирующий что-то извне rootDir хотя я думаю, что неправильно вас понял. Несмотря на это, я согласен с другими здесь в том, что я удивлен, что каталоги за пределами rootDir должны быть явно исключены, как вы описываете.

Нет, я (ранее) говорил, что дерево ссылок может привести к тому, что вещи будут перенесены в ваш исключенный список - немного по-другому.

Ошибка TS6059 сначала немного сбивает с толку, но я считаю, что TS пытается помочь мне не делать ошибок. Если я столкнулся с проблемой определения rootDir, а затем машинный текст plonk вылетает за пределы этого rootDir, тогда TS фактически говорит: «Ой - вы создали машинописный текст, к которому я не могу добраться - это правильно?»

Я либо отвечаю «нет, это неправильно, я напортачил», и перемещаю файлы в rootDir
ИЛИ
Я говорю: «Да, это правильно, и мне очень жаль, что я не сообщил вам» - и затем добавляю его в список исключенных файлов.

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

Либо структура каталогов в выходном каталоге содержит нежелательные родительские папки, либо tsc жалуется на то, что файлы находятся вне корневого каталога.

Это не может быть сложно, правда?

Независимо от того, какие параметры в любой комбинации я использую, tsc похоже, не может обрабатывать монорепозиторий с paths ссылающимся на локальные пакеты в том же монорепозитории. Я пробовал --build , --project , references , paths , extends , rootDir , rootDirs , include , exclude , baseUrl , outDir во всевозможных комбинациях с разными значениями, и в конце он жалуется на файлы, не находящиеся в rootDir иначе он облажается, создав неправильную структуру каталогов внутри outDir .

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

После долгих попыток я смог запустить references в сочетании с paths и больше не подавляется при использовании rootDir .

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

А как насчет файлов, которые не требуют вывода? Наличие файла json вне корня:

const errors = require("../../../../errors.json");

Потому что я не могу скомпилировать версию ES6:

import * as errors from "../../../../errors.json";

Однако с первой версией я теряю безопасность типов.

@mhegazy Вопрос был закрыт 3 года назад. Однако кажется, что спустя 3 года это все еще вызывает недоумение.

Не могли бы вы еще раз просмотреть этот статус «Работает по назначению»? Учитывая реакцию сообщества в этой цепочке, можно с уверенностью сказать, что он ведет себя не так, как ожидает сообщество . Будь то проблема с документацией, переименование этой опции, изменение ее поведения или добавление новой опции, я считаю, что на вашей стороне действительно есть элемент действия, который нужно определить.

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

@ngryman Какой у нас следующий шаг? rootDir имеет определение - это общий корень моих исходных файлов. Когда файл не находится в общем корне, по самому определению rootDir это ошибка. Это определение задокументировано. Я ничего не могу поделать с тем фактом, что люди придумали свои собственные определения для rootDir и впоследствии удивляются.

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

Как я уже упоминал в https://github.com/microsoft/TypeScript/issues/9858#issuecomment -370653478, я думаю, что решение этой проблемы - это просто лучший обмен сообщениями об ошибках. Когда я столкнулся с этим и, в конце концов, обнаружил эту проблему GitHub, мое самое большое разочарование было вызвано тем, сколько времени я потратил, пытаясь выяснить проблему, а затем подумал, что это ошибка компилятора, а затем создал пример воспроизведения, а затем нашел повторяющаяся ошибка с надписью «работает по назначению». Быстрая ошибка с четким сообщением об ошибке спасла бы меня от всего этого.

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

@RyanCavanaugh Спасибо за быстрый ответ.

Если я перейду на эту страницу: https://www.typescriptlang.org/docs/handbook/compiler-options.html. Я прочитал следующее определение:

Задает корневой каталог входных файлов. Используйте только для управления структурой выходного каталога с помощью --outDir.

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

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

Чтобы закончить пример со Starbuck, напишите «смесь эспрессо и парового молока» в списке ингредиентов, чтобы я знал, что такое латте, и мне не приходилось гадать.

Значение файла за пределами rootDir будет заключаться в том, что TS выведет файл за пределы outDir , что я считаю очевидным плохим поведением.

Сообщение об ошибке могло бы быть лучше - мне бы хотелось получить за это предложение или пиар.

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

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

Значение файла вне rootDir будет заключаться в том, что TS выведет файл вне outDir, что я считаю очевидным плохим поведением.

Мне все еще очень непонятно, почему компилятор просто не выполняет chroot для rootDir и не рассматривает файлы вне этого каталога. Как пользователь, которому, вероятно, не хватает контекста о внутренних компонентах и ​​истории tsc для меня это определенно непредсказуемое поведение.

Один из примеров, который я могу вывести из головы, - это Jest, который предлагает тот же вариант: https://jestjs.io/docs/en/configuration#rootdir -string. AFAIK Jest не рассматривает тестовые файлы вне rootDir . Я ожидал бы такого же поведения здесь, например.

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

Я рад, что вы рассматриваете здесь улучшения. Предложение @MicahZoltu может быть интересно изучить.

Со своей стороны, я могу повторить, что я не думаю, что rootDir предсказуемо (отсюда и реакция людей), но, насколько я понимаю, изменение поведения этого варианта не является чем-то, что следует учитывать. Так что в качестве компромисса я мог бы также предложить переименовать rootDir в более значимое имя, кандидатом может быть outBaseDir . Но, наверное, есть лучшее имя.

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

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

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

@ngryman Я согласен с тем, что определение rootDir и то, что он на самом деле делает, похоже, не совпадают. Когда вы создаете новый проект ts (через tsc --init ), комментарий в tsconfig.json для rootDir аналогичен тому, который вы указали в /* Specify the root directory of input files. Use to control the output directory structure with --outDir. */ . Если я предоставлю каталог _input_ файлов, я ожидаю, что единственные из них, компиляция которых будет рассматриваться, находятся в этом каталоге, согласно определению input.

@RyanCavanaugh Возможно, имело смысл сообщить о подобной ошибке 4 года назад, когда машинописный текст использовался только для компиляции в javascript. Конечно, мне не нужны пропавшие файлы! Но теперь, когда популярно исполнение машинописного текста, например ts-node , кажется, что tsc мне немного завидует.

И идея о том, что файлы машинописного текста вне rootDir подразумевают неправильную конфигурацию проекта, просто неверна. Мне не нужны мои модульные тесты, написанные на машинописном тексте, для компиляции в javascript. ts-node просто быстрее, и я могу пользоваться всеми преимуществами машинописного текста при написании тестов.

Я согласен с @CodySchrank . Я в порядке с ошибкой TS, когда какой-то исходный файл внутри rootDir ссылается / импортирует файл за его пределами - этого и следовало ожидать.

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

Интересно, каковы будут последствия превращения этой ошибки в предупреждение. После беглого беглого просмотра кода это определенно кажется возможным, но я определенно не эксперт в процессе сборки tsc. Это похоже на золотую середину между уведомлением о потенциальной проблеме и возможностью обойти ее, если мы захотим.

Настройка src / test / out была ключевым сценарием, рассмотренным в ссылках на проекты.

Для этого требуется как минимум отдельная конфигурация проекта для каждой корневой папки (https://www.typescriptlang.org/docs/handbook/project-references.html). Прочитав инструкции, я ушел, так и не поняв, как реализовать шаблон, и чувствую, что мне вручают отбойный молоток, когда я просил мухобойку.

Конечно, поддержка дополнительных модулей как отдельных подпроектов в моей исходной папке более эффективна, но я не собираю здесь lodash. Я хочу включить множество файлов, таких как файлы тестов и тестов, в общую папку проекта для статического анализа, а когда придет время для компиляции, создать только один каталог для использования внешним миром. Кажется, это достаточно легко указать, и я изо всех сил пытаюсь понять, почему это не только сложно для пользователя, но, очевидно, _verboten_ с точки зрения спецификации TS.

Я хочу подчеркнуть, что единственная причина, по которой эта функция запрещена, связана с предположением компилятора о коррумпированных намерениях со стороны разработчика. Когда разработчик устанавливает "outDir" равным ./src а компилятор находит файл TS в ./test , он _ может_ предположить, что этот файл не нужно генерировать (конечно, при условии, что на него нет ссылок ни в одном файле в "outDir").

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

В нынешнем виде я даже не понимаю, каков законный вариант использования "outDir" . Я предполагаю, что он поддерживает структуру проекта, в которой tsconfig.json находится на верхнем уровне вместе с другими файлами конфигурации и метаданных, а владелец хочет, чтобы скомпилированная папка представляла только исходную папку, вложенную в нее. (Просто убедитесь, что ни один из этих метафайлов не заканчивается на .ts : это было бы абсурдно.)

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

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

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

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

В пользовательском мире это необходимо как-то преодолеть. Я не знаю, делаем ли мы это, расширяя определение исходного кода, а именно. TypeScript, или создав вторую категорию («вспомогательный код», «код проверки», «периферийный код» ...). Это будет код, который, как ожидается, будет работать с теми же определениями типов, что и источник, и который должен успешно проверять, чтобы источник считался правильным, но который не является частью фактической функциональности программы по отношению к ее интерфейсу.

Как потребитель TypeScript я не осознаю специфические трудности реализации такой категории. Однако похоже, что это вписывается в "outDir" : все, что находится внутри "outDir" является частью источника, все, что находится за его пределами, но внутри папки проекта, является частью вспомогательного кода. Главное, что делает это полезным / необходимым, - это появление ts-node, что означает, что я могу выполнять этот вспомогательный код как отдельный шаг, полностью независимый от компиляции; и, конечно, я хочу воспользоваться этим.

не включены неявно какие-либо входные файлы, предоставленные инструменту

Эта проблема возникает именно потому, что пользователь неявно пытается скомпилировать файлы вне rootDir . Вы в основном сказали компилятору «компилировать файлы только в этом каталоге», а затем приступили к ссылкам на файлы вне этого каталога. Компилятор сбит с толку и не знает, как действовать.

/project/source/index.ts

import '../external.ts'

/project/tsconfig.json

{
  "compilerOptions": {
    "rootDir": "./source"
  }
}

В этом примере вы говорите компилятору, что «исходные файлы находятся только в каталоге 'source'». Затем один из этих файлов ссылается на файл, который _не_ в исходном каталоге. Теперь у TypeScript есть две конфликтующие инструкции: одна требует компилировать файлы только в исходном каталоге, а другая - компилировать файлы вне исходного каталога.

@MattiasMartens вы неявно объединяете include и rootDir . Если у вас есть /src и /test , если include равно src/* тогда вы не можете получать ошибки о вещах в /test если только что-то из src неправильно импортировал что-то из test , чему вы должны быть довольны!

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

В любом случае!

Учитывая определение rootDir , когда TypeScript видит файл за пределами предоставленного rootDir , у него есть несколько вариантов:

• Создайте файл выше outDir (при условии, что это вообще возможно!), Что противоречит инструкции пользователя о местоположении вывода.
• Обработайте файл, но не генерируйте его, поскольку при отсутствии других шагов сборки программа будет неработающей.
• Выдает ошибку, потому что проект неправильно настроен

Я категорически возражаю против того, что по умолчанию должна быть выбрана нерабочая программа . Если запрос функции здесь просто рассматривать файлы .ts найденные за пределами rootDir как .d.ts , это разумно, это просто отдельная вещь от rootDir означает что-то кроме rootDir . Как бы вы назвали такой флаг?

@MattiasMartens вы неявно объединяете include и rootDir . Если у вас есть /src и /test , если include равно src/* тогда вы не можете получать ошибки о вещах в /test если только что-то из src неправильно импортировал что-то из test , чему вы должны быть довольны!

Это правда. Я поиграл с include и обнаружил, что в этом случае он работает лучше, чем я думал, в том числе с инструментами VSCode.

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

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

Меня это смущает. Считаете ли вы rootDir проверкой принуждения к подписке? Это влияет на то, что в конечном итоге испускается, поэтому это явно не _только_ проверка принуждения.

Некоторые флаги, такие как target , радикально меняют то, что будет выдаваться - это не проверки исполнения, а инструкции компилятора. rootDir читается и документируется как инструкция компилятора.

Я категорически возражаю против того, чтобы по умолчанию использовалось _выпускать неработающую программу_.

Из того, что я читал об этой теме, похоже, существует широкий консенсус в отношении того, что ссылка из файла внутри rootDir на файл за пределами rootDir _ должна быть ошибкой_. Аспект функции, которую я и другие сочли разочаровывающей, заключается в том, что она не останавливается на достигнутом, а фактически выдает ошибку, если находит какие-либо файлы TS в папке проекта за пределами rootDir независимо от того, находится ли файл в rootDir импортирует их или нет.

Стоит повторить: я установил rootDir в папку, в которой находится мой исходный код, компилятор замечает другой код TS в проекте, который не имеет rootDir , и останавливается! Это конкретное поведение не помогает мне понять мой код. Это просто раздражает.

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

Определения могут быть неправильными. Их можно изменить. Для обратной совместимости нет необходимости сохранять определения, только функциональность.

Если запрос функции здесь заключается в том, чтобы просто обрабатывать файлы .ts обнаруженные за пределами rootDir как .d.ts

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

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

Кажется, что каждый абзац здесь сводится к следующему: « rootDir должен изменить значение по умолчанию include », что было бы разумным предположить, если бы мы добавляли эти флаги сегодня в то же время, но это не принципиальное изменение, которое мы могли бы сделать сейчас. Хотя , возможно , делают все флаги конфигурации взаимодействует друг с другом более возрастает познавательную нагрузку , а не уменьшает его.

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

Файл "tests / foo.ts" находится вне rootDir 'src'. Вы забыли установить шаблон «включить»?

Зарегистрированный # 33515

У меня были проблемы с этим, а также в https://github.com/microsoft/TypeScript/issues/31757#event -2480427393

Взаимодействие между rootDir, include и exclude спроектировано так странно.

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

Текущее определение чертовски странно и крайне не интуитивно.

Как ни странно, сбивает с толку то, что они не взаимодействуют: настройки вообще не влияют друг на друга. include на 100% контролирует то, что находится в программе, а rootDir на 100% контролирует вычисление макета outDir .

Чтобы добавить еще один пример проблемы, это структура моей папки:

tsconfig.json
package.json
src/index.ts

У меня в tsconfig:

"rootDir": "src",
"outDir": "lib",

И в моем "index.ts" (папка src)

import pkg from '../package.json'; // I read the package.json object

export class SomeClass {
  public version = pkg.version;
}

Я _ знаю_, что после сборки файл "index.js" будет внутри папки "lib". И я _ знаю_, что package.json будет на 1 уровень выше.
Я не думаю, что Typescript должен лучше меня знать мою структуру папок и нарушать сборку. Он должен просто зарегистрировать предупреждение о некоторых файлах вне папки rootDir, которые не были включены в выходную папку.

@sebelga Я бы, вероятно, подумал, что это ошибка - разрешение .json извне rootDir было бы в порядке, поскольку TS не копирует это в выходную папку

@sebelga Я бы, вероятно, подумал, что это ошибка - разрешение .json извне rootDir было бы в порядке, поскольку TS не копирует это в выходную папку

Спасибо, неправда .. У нас есть некоторые особые правила для создания файлов .json ... Если файл будет отправлен в том же месте, в самом себе, то только тогда он не будет отправлен. Во всех случаях он генерируется (например, если указан --outDir, он будет отправлен в эту папку)

@RyanCavanaugh У меня есть пример использования, аналогичный @sebelga, где я хочу console.log вывести номер версии из package.json во время выполнения.

Итак, мое решение состояло в том, чтобы изменить мой "rootDir": "." , тогда у меня это включает

"include": [
    "src",
    "typings"
  ]

И поскольку файл package.json включен в папку lib (built), которая содержит подпапку «src», я написал сценарий bash, который запускается сразу после сборки для очистки.

#!/bin/bash

rm lib/package.json
mv $(pwd)/lib/src/* $(pwd)/lib
rm -rf lib/src

Это действительно работает, но мне кажется довольно хакерским.

@sebelga У вас есть файлы .ts папке typings ? В противном случае было бы законным установить rootDir на src и пропустить сценарий.

@sebelga Вместо const { version } require('../../package.json') или import { version } from 'package.json') пробовали ли вы сделать что-то вроде этого:

import { sync as loadJsonFileSync } from 'load-json-file';

const { version } = loadJsonFileSync('../../package.json');

TypeScript не будет заботиться о том, чтобы он таким образом находился вне rootDir .

https://github.com/sindresorhus/load-json-file

Если вы хотите избежать жесткого кодирования всех ../.. вы можете попробовать следующее:
https://github.com/sindresorhus/read-pkg-up

@RyanCavanaugh Я не могу установить его на "src", как упоминалось выше. Я импортирую package.json за пределы нашего src ( import pkg from '../package.json'; ), и tsc этого не позволяет.

Спасибо, что поделились этим @dylang ! Я попробую.

Я сказал машинописному тексту, что мой источник находится в определенной папке (через rootDir)

Это не то, что означает rootDir ! rootDir означает «Используйте эту папку как относительную основу для вычисления путей в outDir ». _ Какие файлы являются частью вашей компиляции - это отдельный вопрос, на который отвечает files и / или include / exclude

@RyanCavanaugh Но это то, что должно означать rootDir , и это то, о чем идет речь.

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

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

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

Это конфликт, эта дискуссия, которая длилась годами по поводу того, что кажется определением свойства rootDir. И что делать с этим вопросом.

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

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

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

Можем ли мы работать вместе и решить эту проблему? Я был бы так счастлив, если бы эти красные линии исчезли ...

@nullquery Если tsc работает, но ваша IDE показывает красные волнистые линии, это означает, что ваша IDE не использует ту же версию или конфигурацию компилятора, что и tsc .

@nullquery файл ошибку, которая показывает, как воспроизвести проблему, и мы либо исправим ее, либо сообщим вам, что не так с конфигурацией вашего проекта.

Следуя обходному пути

tsc --module commonjs --target ESNext --outDir ./edition-esnext --project tsconfig.json && test -d edition-esnext/source && ( mv edition-esnext/source edition-temp && rm -Rf edition-esnext && mv edition-temp edition-esnext ) || true

Пример использования здесь.

Boundation применит его автоматически.

Решение - ссылки на проекты .

Чтобы использовать это, отредактируйте файл "tsconfig.json" и добавьте его в конец файла (за пределами compilerOptions):

"references": [
    { "path": "../common" }
]

Это позволит вам ссылаться на файлы в папке "../common/" (и во всех подпапках).

Мое предыдущее замешательство было связано с тем, что IntelliJ и моя незапятнанная задача gulp-typescript давали мне разные результаты, несмотря на использование одного и того же файла tsconfig.json.

Оказывается, по какой-то причине "gulp-typescript" пробует лучший подход к компиляции.

Ошибка в TypeScript (например, let z: number = '' ) будет отмечена в IntelliJ, но "gulp-typescript" компилирует ее нормально.
Только синтаксические ошибки JavaScript (например, let 1z = '' ) помечаются "gulp-typescript".

Итак, если вы пользователь "gulp-typescript", вы можете столкнуться с такой проблемой в зависимости от вашей версии "gulp-typescript" и вашей конфигурации. (Я использую последнюю версию на момент написания, но предполагаю, что это может прочитать кто-то из будущего. Надеюсь, сейчас для вас лучше.)

Я знаю, что использование Project References похоронено где-то в этой лавине ответов, но было бы лучше, если бы это было задокументировано лучше.

Все три лучших результата по запросу "TS6059" в Google приводят к проблемам с GitHub. Для меня было бы намного яснее, если бы существовала страница, документирующая эти распространенные ошибки и их решения.

@MicahZoltu Это то, что можно решить? Должен ли я создавать новый выпуск или это было бы быстрее, если бы оно обсуждалось внутри компании между основными участниками?

(FWIW Я не часть команды TypeScript)

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

Что касается gulp-typescript, похоже, что версия TSC, используемая gulp-typescript, отличается от версии TSC, используемой IntelliJ. Когда вы видите симптомы, подобные описанным вами, обычно это и есть проблема (во-вторых, они не используют тот же tsconfig.json ).

Версия, используемая "gulp-typescript", должна быть идентична; обе версии являются производными от node_modules . Я пробовал разные способы как для обнаружения ошибок, так и для изменения связанных с ними настроек (включая возиться с различными «репортерами», предоставляемыми «gulp-typescript», и попытки переопределить настройки, чтобы выдавать больше ошибок. Ничего не работает.

Хотя это нормально. Пока IntelliJ выдает мне ошибки, я рад согласиться с тем, что задача Gulp их игнорирует.

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

Я не верю в «допущение совместимости по причинам наследия», особенно когда дело касается ссылок на проекты. _Должна быть возможность ссылаться на файлы за пределами rootDir иначе у вас просто не будет свободы определять структуру проекта таким образом, который имеет смысл для вас и вашей команды.

Когда я впервые начал работать с TypeScript, я столкнулся с множеством проблем. Из их:

• В то время казалось, что решение для включения файлов JavaScript - это AMD. Веб-сайт казался официальным, и в Интернете было много примеров использования AMD в производстве. Но очевидно, что Webpack был новой большой вещью, и поэтому некоторые проекты просто не работали в среде AMD. Извлеченный урок: не все будут применять новый метод, поэтому вам всегда будет плохо.

• Мне не был ясен путь от TypeScript к завершенному минифицированному JavaScript (с сопоставлением источников). В то время было доступно несколько различных методов, но ни один из них не работал изначально с файлами tsconfig.json и / или моей IDE в то время. Извлеченный урок: если вы хотите, чтобы что-то было сделано правильно, вы должны сделать это сами; не полагайтесь на других людей, которые сделают работу за вас, какими бы благими намерениями они ни были, никто не совершенен, и никто не может предсказать ваше рабочее пространство.

• У меня была одна особенная вещь: способ конвертировать содержимое HTML-файлов в словарь JavaScript для включения. Это должно было быть моим единственным камнем преткновения, но в итоге оказалось, что это один из самых простых сценариев для написания.

В итоге мне пришлось разработать свой собственный Gulpfile, чтобы справиться со всем. Он делает следующее:

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

• Компилирует TypeScript в соответствии с локальным файлом tsconfig.json, который генерирует отдельные файлы в выходном каталоге (используя outDir ), поэтому я могу быть уверен, что TypeScript компилируется в моей среде IDE так же, как и в Gulp. (хахахахаха!), затем использует плагин «rollup» для сжатия этих файлов в один файл JavaScript, затем запускает UglifyJS для минимизации этого файла, при этом сохраняя исходное сопоставление, которое сопоставляется с исходным файлом TypeScript.

• (Специальная задача) Создает файл JavaScript, содержащий словарь с именем html_templates для каждого файла HTML в корне источника TypeScript, и помещает его в мою корневую папку в виде уменьшенного файла JavaScript.

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

Подход, который я выбрал, работает, его достаточно просто понять (особенно теперь, когда я понимаю, что «gulp-typescript» делает что-то другое), и я, вероятно, буду использовать его еще долгие годы.

Лучшее решение - это то, что вы понимаете сами. Хотя это не помогает никому, кто пытается мне помочь (что я очень ценю! Я имею в виду помощь, а не путаницу), я могу сказать по опыту, что всегда будет что-то не так с _ любым_ решением, поэтому лучше придерживаться чего-то вы владеете собой, чем то, что разработано, разработано и произведено мультикультурной командой различных убеждений, сексуальной ориентации и гендерной идентичности .

tl; dr, пожалуйста, не нарушайте ссылки на проекты. Мне это нужно, чтобы мои инструменты работали. Спасибо

Я отказался от настройки многопроектного TS и просто сделал tsc -w в каждом проекте и npm link , а затем вы можете просто игнорировать все сложности многопроектного tsconfig и просто обратиться к другим проект, как будто это простые зависимости node.js в node_modules .

Но сегодня в одном проекте я изменил цель с es5 на es6 и он больше не будет компилироваться, потому что File '.../lib.ts' is not under 'rootDir' .

Файловая структура:

/app
 - tsconfig.json // rootDir = "."
 - app.ts (

/app/node_modules/lib
 - tsconfig.json // rootDir = "."
 - lib.ts
 - lib.js
 - lib.d.ts

Почему tsc в /app заботит /app/node_modules/lib/lib.ts файл? Он вообще не должен использовать этот файл. Там скомпилированы /app/node_modules/lib/lib.js и /app/node_modules/lib/lib.d.ts .

Если /app/node_modules/lib/lib.ts удалено - сюрприз - компилируется нормально.

@alexeypetrushin вы можете взглянуть на некоторые из моих проектов. Вроде нормально работает. например:

• https://github.com/unional/standard-log
• https://github.com/mocktomata/mocktomata

import * as pkg from '../package.json';

НЕА. И я не могу найти способ отключить эту ошибку.

@SephReed : Я потратил 200 репутации на StackOverflow, и кто-то внес это очень простое решение для импорта ../package.json . Все, что вам нужно сделать, это поместить файл typings.d.ts в тот же каталог, что и package.json , со следующим содержимым:

declare module '*.json';

Понятия не имею, как это работает, но, честно говоря, мне все равно. На этом этапе TS разветвлялся для себя, а не для меня.

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

repo/
⊢ config/  << provide TS support, but don't build this directory
  ⨽ webpack.config.ts 
⊢ scripts/  << provide TS support, but don't build this directory
  ⨽ release.ts
⊢ src/        << build this directory
  ⨽ example.ts
⨽ tsconfig.json

Поэтому я использую "rootDir": "src" чтобы файлы направлялись в dist а не в dist/src . Но, конечно, TypeScript любит жаловаться на эту настройку, но, поскольку я использую Webpack, для меня это не ошибка.

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

Параметры, которые задают папки и файлы, которые tsc учитывает при совместимости: «файлы», «включить», «исключить».

Тогда для чего вы используете rootDir?
rootDir - это корень структуры каталогов (иерархии) ваших исходных файлов, который tsc использует для создания той же структуры каталогов, начиная с каталога tsconfig.json или "outDir", если он указан. Так что это не тот путь, который tsc использует в качестве базового пути для "outDir". "outDir" - это просто корень, который tsc создает выходные файлы.
Например, предположим, что ваш проект Java имеет такую ​​структуру каталогов.

- src
  - main
    - java
    - resources
      - static
        - js
        - ts
          test.ts

Когда вы устанавливаете "include" и "rootDir", как показано ниже, tsc сгенерирует вывод как:

"include": "src/main/resources/static/ts" *
"rootDir": "." *

- src
  - main
    - java
    - resources
      - static
        - js
        - ts
          test.js *
          test.ts

Если вы также установите "outDir", как показано ниже, tsc сгенерирует вывод как:

"include": "src/main/resources/static/ts"
"rootDir": "."
"outDir": "build" *

- build
  - src
    - main
      - resources
        - static
          - ts
            test.js *
- src
  - main
    - java
    - resources
      - static
        - js
        - ts
          test.ts

Вероятно, вы хотели этого, установив опцию «rootDir» и изменив опцию «outDir», как показано ниже.

"include": "src/main/resources/static/ts"
"rootDir": "src/main/resources/static/ts" *
"outDir": "src/main/resources/static/js" *

- src
  - main
    - java
    - resources
      - static
        - js
          test.js *
        - ts
          test.ts

Поэтому, когда вы установили опцию «rootDir», которая не покрывает объем файлов, кроме опции «exclude», tsc не сможет построить, потому что это не имеет смысла с целью опции «rootDir».

Да, это совершенно плохая практика именования. Это должно было быть просто rootOfStructureOfInputs или что-то в этом роде. Кроме того, outDir должен был быть просто rootOfOutputs.

То, что вы видите на SS, не является проблемой WebStorm - это исходит от TS DevServer.
Второй рекомендуемый импорт - хрень. Поднимается из исходной папки "общение". Я не знаю, кто, черт возьми, должен этого хотеть. Компиляция файла с таким импортом создает множество проблем.

Я также пробовал:

"exclude": ["lib", "node_modules",
        "..", "../..", "../../..", "../../../..", "../../../../..", "../../../../../.."
    ]

Тоже не решила проблему

@mhegazy Вы пометили эту проблему как «Работа по назначению», но это не так. Как вы можете видеть на моем снимке экрана, tsc-server предоставляет файлы вне моего rootDir (в данном случае mobiservice / src) в качестве предложения по импорту. Мне это кажется ошибкой ...