Используете ли вы какой-либо другой инструмент связывания, такой как browserify или webpack, для сгенерированного вывода? или вы ожидаете, что это будет работать непосредственно на узле?

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

Ну и для добавления контекста, "paths" предназначен для использования с загрузчиками, допускающими переназначение, в отличие от Node.js require() . Предполагаемое поведение состоит в том, чтобы позволить TypeScript разрешать информацию о типе для различных идентификаторов модулей, используемых различными загрузчиками, а не перезаписывать идентификаторы модулей. По сути, это не то, что вы думали. На мой взгляд, и не должно, он должен иметь возможность только отражать стратегии разрешения загрузчиков.

@mhegazy Я ожидал, что он будет работать напрямую с node. Это для серверного приложения. Правильно ли @kitsonk заявляет, что это работает так, как задумано, и машинописный текст не будет переписывать пути к модулям?

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

аналогичный ответ https://github.com/Microsoft/TypeScript/issues/9910#issuecomment -234729007

Все хорошо, спасибо. Возможно, было бы полезно лучше задокументировать это, чтобы не запутать больше людей. Теперь я использую https://www.npmjs.com/package/module-alias , чтобы он работал с node.

Оценивая позицию TS, вот простое решение для 90% случаев использования для тех из нас, кто использует Node, но хочет удобства использования относительных $# baseUrl require() вызовов require() без суеты.

Это решение перехватывает вызов узла require() и разрешает запросы, используя имя каталога «main», чтобы имитировать baseUrl . Поэтому предполагается, что параметр компилятора baseUrl также был установлен в тот же каталог, где находился исходный файл «main.ts».

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

import * as path from 'path'
import * as fs from 'fs'
(function() {
  const CH_PERIOD = 46
  const baseUrl = path.dirname(process['mainModule'].filename)
  const existsCache = {d:0}; delete existsCache.d
  const moduleProto = Object.getPrototypeOf(module)
  const origRequire = moduleProto.require
  moduleProto.require = function(request) {
    let existsPath = existsCache[request]
    if(existsPath === undefined) {
      existsPath = ''
      if(!path.isAbsolute(request) && request.charCodeAt(0) !== CH_PERIOD) {
        const ext = path.extname(request)
        const basedRequest = path.join(baseUrl, ext ? request : request + '.js')
        if(fs.existsSync(basedRequest)) existsPath = basedRequest
        else {
          const basedIndexRequest = path.join(baseUrl, request, 'index.js')
          existsPath = fs.existsSync(basedIndexRequest) ? basedIndexRequest : ''
        }
      }
      existsCache[request] = existsPath
    }
    return origRequire.call(this, existsPath || request)
  }
})()

Если вы собираетесь использовать пакет module-alias , упомянутый mika-fischer, обратите внимание, что пути, которые вы регистрируете в пакете, не должны заканчиваться на / , а пути относятся к пути где package.json (это может быть очевидно, но хорошо, чтобы это было ясно),

Итак, если у вас есть это в вашем файле tsconfig:

"outDir": "./dist",
"baseUrl": ".",
"paths": {
  "foo/*": ["./src"]
}

Вы должны зарегистрировать это в своем package.json :

"_moduleAliases": {
  "foo": "dist"
}

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

Попал сюда после того, как потратил некоторое время, пытаясь настроить его в большом проекте.
Если это поведение не изменится, по крайней мере, вы можете обновить документацию, прежде чем закрывать эту проблему.
Официальная документация https://www.typescriptlang.org/docs/handbook/module-resolution.html#path -mapping%20docs ничего не говорит о необходимости использовать «загрузчики, позволяющие переназначать».

установите и запустите "tspath" в папке вашего проекта... https://www.npmjs.com/package/tspath

@ef-carbon/tspm

Также вы можете попробовать "momothepug/tsmodule-alias" для разрешения псевдонима:

https://www.npmjs.com/package/@momothepug/tsmodule -псевдоним

У меня работал только https ://www.npmjs.com/package/module-alias...

Мне тоже удалось заставить это работать с псевдонимом модуля, с недостатком, заключающимся в том, что я должен отслеживать свои псевдонимы как в tsconfig.json, так и в package.json. Кто-нибудь нашел более простое решение?

Решение, указанное @mattyclarkson , также работает, но я не смог найти способ использовать его вместе с ts-node. Есть идеи?

Взгляните на https://github.com/momoThePug/tsmodule-alias .

2018-05-31 15:04 GMT-05:00 [email protected] :

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

Решение, указанное @mattyclarkson
https://github.com/mattyclarkson тоже работает, но я не смог найти способ
использовать его бок о бок с ts-node. Есть идеи?

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-393662306 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/ACKT9JWIkb0Wekz0H_Z3zKXvoE-49EIBks5t4EzkgaJpZM4J6vZQ
.

Спасибо @DanyelMorales , это действительно удобно.

пожалуйста! :)

2018-05-31 16:35 GMT-05:00 [email protected] :

Спасибо @DanyelMorales https://github.com/DanyelMorales , это действительно
удобный.

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-393688075 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/ACKT9GNo30wNv4ZWzSwm_Lv4vesLPI3xks5t4GIzgaJpZM4J6vZQ
.

Может ли кто-нибудь сказать мне, в чем смысл этой функции, если выдаваемые пути на самом деле неверны? То есть, если компилятор TypeScript доволен этим, но конечный результат не запускается - каков вариант использования этой функции?

Как сделать сопоставление относительных путей для вещей, которые НЕ являются модулями, т.е. не импортируются?

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

const starterDir = path.resolve(__dirname, './templates/starter')

поскольку typescript компилирует скрипт и записывает его в другой каталог (на основе конфигурации), __dirname больше не будет приводить к указанному выше разрешению пути. Что было бы решением этого?

Как сделать сопоставление относительных путей для вещей, которые НЕ являются модулями, т.е. не импортируются?

Это действительно вопрос «как использовать Node.js и TypeScript», и его гораздо лучше задать в Gitter.im или StackOverflow.

Я люблю TypeScript, но это безумие.

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

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

Эль Джуэ, 20 сентября. де 2018 г., 02:50, Джош Пайк, notifications @github.com
описание:

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

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-423077950 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/ACKT9DD_z4KOHpfwddTomMXujEsza9tQks5uc0jbgaJpZM4J6vZQ
.

+1!

webpack может помочь мне разрешить карты путей (или другой инструмент, например babel-plugin-module-resolver ), но не объявления ( .d.ts ) .

Все пути в объявлении не разрешены.

Столкнулся и с этой проблемой. Казалось логичным, что испускаемый код будет включать сопоставление путей. Прибегнул к псевдониму модуля . Но +1 для Typescript, чтобы опционально предоставить эту функциональность.

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

+1

Вы можете скомпилировать абсолютный и основанный на пути импорт TypeScript в относительные файлы Javascript, используя ts-transformer- imports и ttypescript

Я создал решение времени компиляции, в котором вы можете продолжать использовать tsc . https://github.com/joonhocho/tscpaths

Microsoft/TypeScript#15479 (комментарий)

Я только что столкнулся с этой проблемой при попытке заставить vue-cli выводить файлы d.ts, где много import {foo} from "@/some/folder/foo" , а выводимые файлы d.ts не разрешают псевдоним.

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

Задача компилятора состоит в том, чтобы выводить действительные файлы javascript И d.ts для ваших машинописных файлов, и это просто не работает в этом допустимом сценарии (с использованием псевдонима пути в файлах tsconfig).

Я немного запутался в этом вопросе. Он был закрыт и помечен как «Работает по назначению». Я понимаю, что Typescript предназначен для вывода недопустимого источника? Кажется странным.

Нищие не могут выбирать, но использование Typescript позволяет избежать многих разочаровывающих аспектов ванильного JS, и я считаю относительный импорт ('../../../../../utils/parser') одним из них. Было бы замечательно, если бы Typescript мог их очистить!

@codeitcody Похоже на то. Глупо, что он выводит что-то, что просто не работает без какого-то стороннего пакета, но это реальность.

Что ж, разве это не приятная проблема?

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

Эта проблема существует уже 2 года, и пока нет официальной информации о том, будет ли она реализована или нет.

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

@mhegazy Можете ли вы или кто-то другой сообщить нам, если сейчас, два года спустя, возможно, команда TypeScript взглянет на это еще раз и передумает?

webpack может помочь мне разрешить карты путей (или другой инструмент, например babel-plugin-module-resolver ), но не объявления ( .d.ts ) .

Все пути в объявлении не разрешены.

Есть ли способ добиться этого? У меня есть пользовательская библиотека компонентов реакции, и я получил эту ошибку при попытке использовать paths для псевдонима. Я делаю 2 бандла с роллапом и типами с --emitDeclarationOnly

Я не могу использовать псевдоним модуля, потому что он говорит:

ВНИМАНИЕ: этот модуль не следует использовать в других модулях npm, так как он изменяет поведение запроса по умолчанию!

Пожалуйста, помогите проголосовать за этот пост на Reddit: https://www.reddit.com/r/typescript/comments/a07jlr/path_maps_cannot_be_resolved_by_tsc_works_as/
Не знаю, зачем здесь нужна эта огромная дискуссия. Эту ошибку должно быть легко решить. Опция в tsconfig, и каждый может решить, хочет ли он текущего поведения (по какой-либо причине) или рабочего подхода.

У нас была такая же проблема в Dropbox, и мы открыли исходный код этого преобразователя https://github.com/dropbox/ts-transform-import-path-rewrite.

У меня был один и тот же опыт несколько раз, я ожидаю, что псевдоним пути будет разрешен, но я все время забываю, что мне нужно установить псевдоним модуля, обновить package.json и импортировать его в основной файл. Было бы здорово, если бы это было обработано на этапе компиляции с помощью Typescript.

Ой. Это настоящий удар по TypeScript. Где в этом смысл?

ps А нельзя ли просто прокомментировать +1

Добро пожаловать в клуб @def14nt. Мы — счастливая группа мечтателей, мечтающих о лучшем будущем и терпеливо ожидающих того дня, когда в TypeScript будет реализован простой и разумный вариант компилятора, облегчающий нашу жизнь. Когда этот день, наконец, наступит, не забудьте проверить небо на наличие дородных розовых тел свиней, когда они величественно улетают в закат на своих новообретенных крыльях.

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

@мика-фишер
Как использовать https://www.npmjs.com/package/module-alias , чтобы eslint перестал предупреждать о «неразрешенном пути» @root/bla/bla (в файлах JS)? А как включить автодополнение для таких путей в WebStorm и VS Code?

Для меня автозаполнение импорта работает в VSCode по умолчанию в проектах машинописи.

@bobmoff Да, похоже, все хорошо для импорта файлов TS из файлов TS.
Но автодополнение и навигация для `require('@root/bla/bla') из файлов TS не работают.

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

Потому что, если я переименую только один файл JS в TS, все относительные пути в каталоге build будут нарушены (вероятно, я должен использовать «allowJs: true», но у меня есть один проект с 2 гигабайтами файлов JS, это так) странно компилировать их в директорию сборки %)).
Хорошо, я пытаюсь решить эту проблему с помощью псевдонимов модулей, и навигация и автозаполнение моей IDE перестают работать, и eslint предупреждает о 100500 «неразрешенных путях». Я уже немного ненавижу TS, кажется, что миграция для больших JS-проектов не так проста, как говорят люди из TS-маркетинга. Кажется, что миграция бэкенд-проектов JS на golang проще :)

Я успешно использую tscpaths в качестве обходного пути.

Я тоже. Я действительно рекомендую tscpaths . Он работает так, как должен.

Мой простой обходной путь:

node -r ts-node/register/transpile-only -r tsconfig-paths/register index.js

Или с pm2 process.yml

apps:
  - name: 'my-app'
    script: './dist/index.js'
    instances: 'max'
    exec_mode: 'cluster'
    out_file : '/dev/null'
    error_file : '/dev/null'
    node_args: ['--require=ts-node/register/transpile-only', '--require=tsconfig-paths/register']
    env_production:
      NODE_ENV: production

Просто наткнулся на это, иногда TypeScript может быть настоящей занозой в заднице.

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

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

....или начните обсуждение в Apple, Google и Microsoft
попросив их реализовать функциональность в своих движках JavaScript, чтобы
они могут
интерпретировать ваши псевдонимы ;-)

Компилятор TypeScript делает именно то, что должен делать!

Если вы работаете в мире Angular, дорога проложена, если вы хотите
запустить свой
код непосредственно в Node, вам понадобится инструмент для разрешения путей, и у меня есть
сделанный
такой инструмент специально для вас, он используется в производстве уже больше года,
это происходит
используется крупнейшей газетой Швеции, я сделал это, чтобы вы могли
оголяться
кость с Node, я не пытаюсь ничего здесь продать, я не зарабатываю деньги
из этого :)

И да, есть такие инструменты, как "tsmodule-alias" и подобные хаки, вы можете
на самом деле заставить это работать
если вы очень-очень осторожны, но это беспорядок, есть обходные пути, используя
ц-узел,
сценарии оболочки и т. д. и т. д. ... бла-бла-бла

Я, наконец, почувствовал, что этого достаточно, поэтому я заперся и сделал
ЦПуть
псевдонимы времени компиляции

> npm установить -g tspatj

мой проект> ТСК

мой проект> tspath

или

мой проект> tspath --f

безголовый (оказался очень полезным на сервере сборки)

и все готово, ваши файлы javascript теперь имеют
правильные относительные пути, разве это не то, что мы хотим здесь?

Ваше здоровье! :)

https://www.npmjs.com/package/tspath

день 13 янв. 2019 кл 22:20 skrev Фабио Спампинато <
уведомления@github.com>:

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

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-453866553 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAAy_7JYrwYo3KOLxpLWP0np5JVz2kQzks5vC6MogaJpZM4J6vZQ
.

@даффман

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

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

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

Компилятор TypeScript делает именно то, что должен делать!

Если бы в этой ветке было полно людей, которые просили tsc также выполнить минификацию или что-то в этом роде, я бы с вами согласился. Однако это не так. Это люди просят, чтобы компилятор сгенерировал исполняемый код. Я действительно не думаю, что это слишком много для компилятора, не так ли?

И он генерирует исполняемый код, если вы не используете функции, которые
не поддерживается движками JavaScript, это должно иметь большой смысл, верно
вот, например: стали бы вы винить компилятор C++, если бы ваше приложение
использует библиотеки динамической компоновки и что программа не будет работать на машине
что они не установлены?

Это функция, которую можно использовать, если вы управляете относительными путями,
взять на себя ответственность за них, как это делает Angular с WebPack или как я с
все мои проекты TypeScript с TSPath!

Не используйте их, если вы не понимаете, как настроить рабочую среду,
Я действительно не думаю, что это ответственность Microsoft, они
предоставил функцию, и вот как она работает,
он может работать не так, как вы хотите или ожидаете, но это не делает
это неправильно!

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

День 14 янв. 2019 кл 21:34 скрев Роберт Основные уведомления@github.com :

Компилятор TypeScript делает именно то, что должен делать!

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

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454151277 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAAy_7FeuOJAnI9bXYSVgf_YghJluTyGks5vDOnEgaJpZM4J6vZQ
.

Это функция, которую можно использовать, если вы управляете относительными путями, берете на себя ответственность за них, как это делает Angular с WebPack или как я делаю со всеми моими проектами TypeScript с TSPath!

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

Тот факт, что TS нужен внешний упаковщик только для того, чтобы можно было выполнить выведенный код, просто нелеп.

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

Я всегда понимал, что TypeScript должен компилироваться в JavaScript. Если вы говорите мне, что определенные функции не поддерживаются движками JavaScript, то почему именно они там есть?

Вы бы обвинили компилятор C ++, если библиотеки динамической компоновки вашего приложения и что программа не будет работать на машине, на которой они не установлены?

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

Вы действительно не понимаете этого, не так ли? Код не взломан, если он
сломано, потому что вы настроили компилятор
для генерации кода, который ваша "платформа" не поддерживает, в этом случае
псевдонимы!

В вашем случае не используйте псевдонимы, "вы" их не поддерживаете, серьезно!

Даже если это будет исправление в 1 строку (конечно, это не так), это
вопрос о том, что компилятор должен и
не следует делать! Эта функция была добавлена ​​для того, чтобы ПОДДЕРЖКА ЗАГРУЗЧИКОВ не
наоборот, читайте
в Path Mapping в официальной документации, так что опять же, вы его используете
неправильно!

Опять же, эта функция предназначена для загрузчиков/резольверов, вы неправильно поняли, как она
работает, так что нет, майкрософт
не следует изменять компилятор, чтобы вы могли вставлять псевдонимы без
среда, которая поддерживает это!

День 15 янв. 2019 кл 04:41 skrev Фабио Спампинато <
уведомления@github.com>:

Это функция, которую можно использовать, если вы управляете относительными путями,
взять на себя ответственность за них, как это делает Angular с WebPack или как я с
все мои проекты TypeScript с TSPath!

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

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

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454256799 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAAy_zuWKV0qzzWt6_jZNgDLFt1TA0tMks5vDU3vgaJpZM4J6vZQ
.

Они существуют, поскольку загрузчики используют сопоставление путей, поэтому оно поддерживается!
И раз уж вы настаиваете (как и я) на их использовании без загрузчика, в чем смысл
проблема с
с помощью инструмента, чтобы вы могли использовать эту функцию?

День 15 янв. 2019 кл 05:10 скрев Роберт Основные уведомления@github.com :

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

Я всегда понимал, что TypeScript должен компилироваться в
JavaScript. Если вы говорите мне, что некоторые функции не поддерживаются
Движки JavaScript, тогда почему именно они там?

Вы бы обвинили компилятор C++, если динамическая ссылка вашего приложения
библиотеки и что программа не будет работать на машине, не имеет этих
установлены?

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

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454260977 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAAy_25-ZmS235i1Ic7mvSzEt2QJDX6Bks5vDVTAgaJpZM4J6vZQ
.

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

Пожалуйста, укажите мне на этот раздел документации.

это 15 янв. 2019 кл. 05:31 skrev Роберт Мейн уведомления@github.com :

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

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454263854 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAAy_8e5v8IV-ynmjRTeoC3cp5llwnsIks5vDVm8gaJpZM4J6vZQ
.

Эта функция была добавлена ​​для того, чтобы ПОДДЕРЖКА ЗАГРУЗЧИКОВ не
наоборот, читайте
в Path Mapping в официальной документации, так что опять же, вы его используете
неправильно!

https://austinknight.com/wp-content/uploads/2015/04/DesignVSUX.jpeg

@duffman Разве ты не видишь, что люди просто хотят эту функцию??? Вы всем говорите, что он/она слишком туп, чтобы понять, как использовать эту "фичу". Хорошо, вы можете смотреть на это так, но кто знает, может быть, все наоборот...

Кстати, мое мнение следующее:

Так как псевдонимы встроены в компилятор и компилировать проект с ними нормально. Это может заставить пользователей думать, что это работает так, как предполагает (и эта проблема является хорошим доказательством того, что я прав). Это даже кажется нелогичным - почему что-то работает в "официальном" редакторе (vscode - особенно при использовании функции "автоматического импорта", vscode использует псевдоним пути), почему копилятор также работает нормально, когда результирующий код не работает? Когда я говорю, что «движок js его не поддерживает», у меня возникает желание спросить еще больше — разве TS не предназначался для смягчения некоторых «проблем» JS?

Я бы ожидал одного из двух решений этого:
1) Корректное переопределение импорта с псевдонимами
2) Показ предупреждения

Говорить «это правильное поведение», я думаю, неправильно. Это не. TS — это не ассемблер, даже не C/C++.

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

Хорошо бы Майкрософт!!!!!!

Умоляем вас, нам нужна ваша помощь для улучшения приложений с псевдонимом.

:( здесь все грустные и злые( и голодные) из-за отставания
последовательность. Типографика классная, мне нравится...

Мы это любим!

С уважением, бездомный разработчик...

Эль Мар., 15 де эн. де 2019 г., 08:02, Майк С[email protected]
описание:

Кстати, мое мнение следующее:

Псевдонимы встроены в компилятор, компиляция в порядке. Это может заставить пользователей
думают, что это должно работать так, как они думают (и этот вопрос в значительной степени
хорошее доказательство того, что это правда). Кажется нелогичным - почему что-то работает в
«официальный» редактор (vscode — особенно при использовании функции «автоматического импорта»,
vscode использует псевдоним пути), почему копилятор также работает нормально, когда результирующий код
не работает? Когда я говорю, что «движок js не поддерживает это», у меня возникает желание спросить
даже больше - разве TS не предназначался для смягчения некоторых "проблем" JS?

Я бы ожидал одного из двух решений этого:

1. Корректное переопределение импорта с псевдонимами
2. Отображение предупреждения

Говорить «это правильное поведение», я думаю, неправильно. Это не. ТС нет
язык ассемблера, даже не C/C++.

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454384357 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/ACKT9OqexgOaHH1vDFuRcO7U_r2DEC23ks5vDdFbgaJpZM4J6vZQ
.

. TS — это не ассемблер, даже не C/C++.

Я действительно не понимаю, на что вы пытаетесь указать, утверждая, что TS — это не C++, я думаю, что большинство из нас хорошо это знают!

Мы также установили, что сопоставление псевдонимов/путей используется в производстве по всему миру, поэтому, естественно, VS Code должен поддерживать это, но это все еще не аргумент для MS создавать компилятор для вашей установки!

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

Я имею в виду, что вы можете настроить рабочую среду разработки TS с псевдонимами путей примерно за 2 минуты, если вы не хотите использовать WebPack, вы можете использовать TSPath для разрешения всех путей во всех файлах js за 1 секунду, добавьте его в пакет .json в качестве скрипта запуска, и вам даже не нужно об этом думать, проблемы не существует, компилятор остается таким, каким он был задуман, и вы можете продолжать счастливое ура!?

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

Приглашаем пятерку лучших авторов TypeScript: @ahejlsberg @andy-ms @DanielRosenwasser @sandersn @sheetalkamat

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

Статус этой проблемы не оставил мне другого выбора, кроме как понизить TS до должности только проверяющего типа.
Babel теперь имеет достойную поддержку синтаксиса TS и вместе с babel-plugin-module-resolver прекрасно справляется с работой по созданию рабочего кода для этого варианта использования.
Единственным недостатком является дублирование битов конфигурации из tsconfig.json , поскольку Babel не заботится о конфигурациях TS. Но это приемлемая цена за работу с абсолютными путями в проектах узлов, и в качестве бонуса я получаю всю экосистему с гениальными вещами, такими как макросы babel.

Это минимальная настройка, которую я получил для замены компилятора tsc :

• npm install --save-dev @babel/cli @babel/core @babel/preset-env @babel/preset-typescript babel-plugin-module-resolver @babel/plugin-proposal-class-properties @babel/plugin-proposal-object-rest-spread
• в package.json :
  tsc -> tsc && babel ./src --out-dir ./dist --extensions ".ts,.js"
• в tsconfig.json :

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@mynamespace/*": ["src/*"]
    },
    "outDir": "./dist",
    "noEmit": true, <--
    "allowJs": true,
    "target": "ES2017",
    "module": "CommonJS",
    "lib": [
      "ES2017"
    ]
  },
  "include": [
    "./src/**/*"
  ]
}

• в .babelrc :

{
  "presets": [
    "@babel/preset-typescript",
    ["@babel/preset-env", {
      "targets": {
        "node": true
      }
    }]
  ],
  "plugins": [
    ["module-resolver", {
      "root": ["./src"],
      "alias": {
        "@mynamespace": "./src"
      },
      "extensions": [".js", ".ts"]
    }],
    "@babel/plugin-proposal-class-properties",
    "@babel/plugin-proposal-object-rest-spread"   
  ]
}

Я просто хочу использовать typescript с абсолютным путем, но, похоже, мне нужно настроить webpack или babel или что-то еще, слишком сложно реализовать эту простую функцию, должно быть проще 😞

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

День 28 янв. 2019 kl 15:59 skrev 叶伟伟[email protected] :

Я просто хочу использовать typescript с абсолютным путем, но, похоже, мне нужно
config webpack или babel или что-то в этом роде, это оооочень сложно!!!

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-458164055 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAAy_1_T-An7swSND-xdBhL0HNHxQkm6ks5vHxBggaJpZM4J6vZQ
.

Оставив это здесь, потому что фактический задокументированный вариант использования текущего поведения paths не упоминался в этой теме: пакеты @types/ не поддерживают функции, относящиеся к semver. Однако они включают обновленные типы для старых API, которые я могу использовать. Например, я использую history@2 , когда history@3 является последним.

"paths": {
    "history": [ "history/v2" ]
}

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

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

Во второй раз на общекорпоративном семинаре по ТС мне пришлось объяснять это бессмысленное и постыдное поведение...

Серьезно!

Какой компилятор языка, особенно тот, чей основной рекламный ход — это корректность для JavaScript, выдает неработающий код в качестве «функции»?!?!

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

Вы только посмотрите, сколько раз на это ссылались... Какая пустая трата времени и внимания стольких людей.

Я понимаю ваше разочарование, но то, что многие люди считают поведение правильным, не означает, что это правильно.

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

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

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

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

@kitsonk , все, что ты только что сказал, не соответствует действительности.

Проблема в том, что TS будет работать одним способом во время разработки/тестирования, а другим после завершения компиляции.

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

Это не так, и в этом проблема.

Возможно, карты модулей уменьшат разочарование в будущем. Но наша позиция здесь, наряду с техническими проблемами, которые мы хотим решить, довольно ясны — сопоставление путей отражает поведение внешней схемы разрешения (например, сопоставление путей в AMD и System.js, псевдонимы в Webpack и других сборщиках). Это не означает, что мы изменим ваши пути.

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