Typescript: Подавление ошибки «Путь импорта не может заканчиваться расширением .ts»?

Предположим, у вас есть два файла:
a.ts : import * as b from "./b.ts";
b.ts : export const b: number = 0;

Когда мы компилируем a.ts , мы не меняем спецификаторы импорта . Таким образом, вывод a.js будет содержать тот же спецификатор импорта "./b.ts", хотя, возможно, переведен в require("./b.ts") .
Затем, когда вы попытаетесь запустить a.js это не удастся, потому что не будет b.ts для импорта, только b.js . (Или без --outDir где b.js рядом с b.ts , он разрешит импорт в b.ts , а затем не выполнит синтаксический анализ в : number . )

Вместо этого вы должны опустить расширение файла при импорте или использовать расширение .js .

нет ， я использую означать выполнение файла。 без компиляции。

@ hooper-hc
Я думаю, что мы можем установить tsconfig в качестве временного решения следующим образом:

{
  "compilerOptions": {
    "module": "amd",
    "target": "esnext",
    "baseUrl": ".",
    "paths": {
      "http://*": ["../../../.deno/deps/http/*"],
      "https://*": ["../../../.deno/deps/https/*"],
      "*.ts": ["*"]
    }
  }
}

Я тоже использую означает. Я обнаружил, что комментирование // @ts-ignore каждой строки импорта работает.

// @ts-ignore
import coerceToArray from './journey.coerce-to-array.ts'
// @ts-ignore
import fnFree from './journey.fn-free.ts'
// @ts-ignore
import fnReduce from './journey.fn-reduce.ts'

Есть ли способ отключить это требование глобально в ts-config?

Я также попробовал решение @zhmushan , и оно не

@reggi удалить ./
Надеюсь, что в будущем мы сможем использовать конфигурацию, аналогичную module:deno чтобы упростить операцию.

Будет ли команда TypeScript открыта для добавления "module": "deno" в tsconfig? Таким образом, мы можем поддерживать использование расширения .ts изначально, без необходимости прибегать к чему-то вроде kitsonk / identify_ls_plugin в качестве обходного пути. Он также может попытаться обеспечить его соблюдение, поэтому, если вы попытаетесь сделать

import module from 'module';

он покажет ошибку вроде Cannot have an extensionless import with module:deno (разрешен только импорт полных URL и относительный импорт, начинающийся с ./ или ../ ). Подобная конфигурация также может поддерживать собственный поиск типов в папке $DENO_DIR/deps , поскольку в настоящее время нам нужно использовать параметр пути для обхода этого. Кроме того, автоматический импорт также может работать должным образом, поскольку в настоящее время он всегда выполняет импорт без расширений (что означает, что вам все равно придется вручную редактировать его).

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

В большинстве инструментов экосистемы Javascript вы можете делать такие вещи, как import picture from 'image.png' , что, очевидно, не является Javascript. Предполагается, что какой-то инструмент будет знать, как преобразовать указанный файл в Javascript, чтобы это работало правильно. Так работают все типы ресурсов и альтернативные синтаксисы, такие как JSX.

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

Если бы tsc хотел работать больше, чем остальной мир, он мог бы разрешить .ts в качестве расширения, а затем преобразовать его в .js как часть типов удаления во время сборки. Очевидно, это большое изменение в способе работы компилятора tsc. С другой стороны, существует волна альтернативных инструментов, основанных на Babel и Sucrase, которые начинают входить в экосистему, так что, возможно, есть долгосрочная выгода в согласовании с методами работы этих инструментов.

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

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

Если бы tsc хотела работать как остальной мир

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

@ jpike88 Я не согласен. Я не понимал, что эта проблема существует. Была пара других проблем, которые мы отслеживали. Этот выпуск ничего не говорит о намерениях команды. Это все еще помечено как вопрос, и можно утверждать, что это действительно дубликат # 16577 или # 18442.

Комментарий Райана, тем не менее, раскрывает суть проблемы, что они могут написать что-то, что удовлетворит каждый хост, поэтому они ограничивают это наиболее распространенной ситуацией сегодня, то есть способом CJS Node.js.

Я все еще думаю (и я думал, что уже говорил об этом раньше), что может быть время для "moduleResolution": "literal" который будет делать то, что написано на жестяной коробке, и позволит TypeScript предположить, что какой-либо хост времени выполнения поймет это вне / изменить спецификаторы модуля.

Да, но:

https://github.com/microsoft/TypeScript/issues/18442
Я на самом деле прокомментировал это, как и два года назад, и все равно это предложение стадии 1.

https://github.com/microsoft/TypeScript/issues/16577
Также старше двух лет, все еще в стадии «обсуждения». Также по темпам, это не произойдет в ближайшее время.

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

Эта проблема была помечена как "Вопрос" и в последнее время не наблюдалась. Он был автоматически закрыт на хозяйственные нужды. Если вы все еще ждете ответа, вопросы обычно лучше подходят для stackoverflow .

Аналогичная проблема возникает, если вы хотите напрямую импортировать файл .mjs
например, import { forEach } from https://unpkg.com/[email protected]/index.mjs

Это закрыто, но не исправлено.

Если кто-то здесь просто искал способ запустить ваш TypeScript как в контексте Node.js, так и в Deno, знайте, что Webpack + ts-loader позволит вам сохранить «.ts» в ваших импортированных файлах.

У меня возникает эта проблема всякий раз, когда я импортирую файл из NOM? любое решение, чтобы исправить это, кроме добавления // @ts-ignore ?

Это исправлено? Импорт без расширения в любом случае не является частью JS, использование расширений не должно отображать ошибку.

Я согласен с комментариями выше. Жаль, что проблема еще не решена.
Я нашел расширения для vscode, которые должны помочь, но, к сожалению, они не работают должным образом.
В любом случае, оставлю ссылки здесь:
1) https://github.com/justjavac/vscode-deno
2) https://github.com/axetroy/vscode-deno

После @ TicTak21 :
Обе ссылки, которые он упомянул, теперь устарели и заменены официальным подключаемым модулем:
https://github.com/denoland/vscode_deno
Это расширение исправляет импортируемые файлы .ts и URL (так что ошибок больше нет),

@danbulant Я все еще вижу ошибку при использовании плагина vscode_deno.

Я также использую Deno, но думаю, проблема здесь не в том, что .ts vs no .ts . Это больше о возможности разрешить tsc игнорировать любой номер ошибки. Например, что-то вроде tsc --ignore TS2691 .

Расширение Deno для кода vs - это хорошо, но оно не решает проблему, а просто подавляет ошибку в редакторе. У меня есть библиотека, которую я хочу создать для NAME и браузера, но я не могу, потому что tsc выбросит.

@samuelgozi
Согласен на 100%. Это основная причина, по которой я пока не рассматриваю Deno как замену node.js на сервере. Хорошие веб-фреймворки для Deno уже доступны, и только TYPESCRIPT стоит на пути этой прекрасной мечты.

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

Мой конкретный вариант использования заключается в том, что я работаю в среде с кодом машинописного текста, совместно используемым клиентом и сервером с использованием символических ссылок. Сервер написан с учетом обозначения, а клиент написан с использованием обычного машинописного текста и phaser3. Пакет, который я использую, parcel , может обрабатывать машинный текст, импортирующий файлы .ts (по крайней мере, с parcel-bundler ^1.12.4 ). Остается исправить intellisense.

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

Для начала я запустил команду yarn add typescript deno_ls_plugin --dev чтобы установить его. Увидев, что intellisense не исправлен, я заметил небольшой текст внизу файла readme deno_ls_plugin , чтобы использовать версию машинописного текста для

Для тех, кто немного не понимает, как это сделать, вот что я сделал:
Сначала я установил deno_ls_plugin и typescript качестве зависимостей разработки и обновил tsconfig.json включив deno_ls_plugin в качестве плагина.

{
  "compilerOptions": {
    "plugins": [{ "name": "deno_ls_plugin" }]
  }
}

Затем я щелкнул файл машинописного текста и щелкнул версию в правом нижнем углу.

Затем я выбрал версию машинописного текста

и выбрал версию рабочего пространства.

В моем конкретном случае я также установил typescript.tsdk в .vscode/settings.json но я не знаю, нужно ли мне это.

Если кто-то еще пытается поделиться кодом обозначения с кодом машинописного текста, я использовал символические ссылки для ссылки на основной код как на сервере, так и на клиенте, и имел код внутри символической ссылки, ссылаясь на файл deps.ts за его пределами для зависимости (поскольку import_map - это своего рода meh atm), чтобы версия машинописного текста могла импортировать пакет npm, а версия обозначения могла импортировать URL-адреса.

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

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

Эту проблему необходимо открыть повторно.

Разработчики Deno не пользуются здесь заслуженным уважением. Они создали потрясающую среду выполнения на основе TypeScript, но разработчики TypeScript не будут добавлять флаг, позволяющий ей работать должным образом. Как эта печальная ситуация может продолжаться так долго ?!

Невозможность использовать расширение .ts при импорте вызывает огромную боль и проблемы для пользователей Deno, пожалуйста, помогите нам!

это на самом деле не специфично для Deno

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

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

./component.vue
./component.ts

import component from './component';

Почему это закрыто? Конечно, не конкретно Deno, особенно с подъемом mjs

Эта ветка НЕ ​​является вопросом, это запрос функции. Может кто-нибудь поправить ярлык и снова открыть? Добавление // @ts-ignore к каждому импорту вручную не является приемлемым решением.

@zraineri

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

Считайте меня сумасшедшим, но мне кажется, что здесь была какая-то корпоративная солидарность. Компания потратила много денег на узел (npm). И не хочет, чтобы какой-то выскочка собственными руками отнял у них прибыль .. Так что я не думаю, что вы можете ожидать большого дружелюбия к девизу от vscode или машинописного текста.

К счастью, вы можете использовать плагин, который уже делает больше, чем вы просите, и будет только улучшаться.
https://marketplace.visualstudio.com/items?itemName=denoland.vscode-deno

Но проблема не только в Deno, но и в обычных js
https://github.com/microsoft/TypeScript/issues/27481#issuecomment -664401169

@Hulkmaster

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

Я являюсь частью основной команды Deno. Я согласен с тем, что компилятор TypeScript не должен вмешиваться в переписывание спецификаторов модулей. Внутренние компоненты Deno подавляют это диагностическое сообщение, а плагин vscode для Deno также подавляет это сообщение. Это не препятствие для Дено.

Поверьте, не существует какой-то скрытой скрытой группы Microsoft / Node.js, подавляющей Deno. Основная команда TypeScript, член сообщества Node.js и основная команда Deno регулярно общаются друг с другом и сотрудничают.

@kitsonk

Это не препятствие для Дено.

но это препятствие на пути объединения двух миров: Узла и Дено. Как я могу написать машинописный текст, который будет работать на обеих платформах одновременно, если у вас, ребята, есть религиозные разногласия по поводу импорта локальных файлов с расширениями или без них .. Мне придется выбрать сторону

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

Это действительно не проблема с TypeScript / tsc . Node.js в любом случае идет по пути явных модулей, и то, как они справляются с этим, повлияет на возможности разрешения модуля tsc я подозреваю. Я считаю, что там продолжаются разговоры, чтобы иметь возможность лучше поддерживать ESM в Node.js.

Выполнение того, что предлагает эта проблема, на самом деле никому не поможет. Лучшее решение проблемы было предложено в № 33437.