Моей отправной точкой было введение в том, как использовать реакцию и веб-пакет с машинописью: https://www.typescriptlang.org/docs/handbook/react-&-webpack.html. Однако указанные инструкции не решают проблему, заключающуюся в том, что у компонента реакции, который я хочу использовать, нет @types.Итак, мой первый шаг - мне нужно добавить @types.
В модуле scoped @ foo / bar был один важный нюанс: он разбил все свои подкомпоненты на отдельные подмодули, такие как @ foo / bar / X, @ foo / bar / Y и @foo/ bar / Z с самой @ boo / bar, не имеющей функциональности.Как мы увидим, это был важный нюанс, который сделал решение этой проблемы немного сложнее, чем если бы мне не пришлось импортировать модуль с областью действия в мою машинопись.
Здесь есть хороший пост в блоге о том, как импортировать ванильный JavaScript в машинописный текст.К сожалению, у предложенного подхода есть один недостаток.А именно, идея добавления «index.d.ts» в типизацию src / @ имеет две проблемы:
- Она работает только для локального запуска компилятора машинописи (tsc). То естьсделает tsc счастливым, позволив tsc разрешить модуль из вашего локального файла ".d.ts", но веб-пакет все равно потерпит неудачу, если модуль не найден.
- Предложенный подход не научил меня, какиметь дело с модулями области действия, которые имеют разные правила для имен папок в @types
При любом подходе, который я пробовал, я знал, что мне нужно иметь этот оператор импорта в моем файле машинописи:
import X from '@foo/bar/X';
ReactDOM.render(
<X/>,
document.getElementById("example")
);
Где-то мне нужно было следующее в файле объявлений ".d.ts", например index.d.ts, это было очевидно:
declare module '@foo/bar';
declare module '@foo/bar/X';
Но при запуске 'webpack' получилось Module not found: Error: Can't resolve '@foo/bar/X'
Я решил запустить компилятор машинописного текста (tsc) с этим флагом, чтобы увидеть возможные места, где tsc попытается разрешить модуль.
tsc --traceresolution
Используя флаг traceresolution, я смогчтобы увидеть что-тоИнтересно: местоположение в узле node_modules / @ types, где поиск tsc было совершенно неожиданным (и, следовательно, поиск webpack, поскольку webpack следует тем же правилам, что и tsc).Он ожидал найти мой файл index.d.ts в node_modules/@types/foo__bar ПРИМЕЧАНИЕ. DOUBLE UNDERSCORE.Это верно, для пакетов объема вы не можете иметь node_modules/@types/@foo/bar/index.d.ts.Вместо этого вы должны использовать одну папку в @types с именем foo__bar с DOUBLE UNDERSCORE.
С этим знанием я создал @ types / foo__bar.Я скопировал package.json из модуля @ foo / bar в @ types / foo__bar.Я вычистил все скрипты и другие бесполезные вещи, которые не нужны @types, и сократил их до следующего:
{
"name": "@types/@sfoo/bar",
"version": "2.6.0",
"peerDependencies": {
"react": "^16.3",
"react-dom": "^16",
"styled-components": "^3"
},
"dependencies": {
...
},
"engines": {
"node": ">=6"
},
"gitHead": "ac0288aaa47a4f15e56db3a5eff4424fb7905419",
"main": "",
"types": "index"
}
Но все же была еще одна проблема!Даже после того, как tsc смог разрешить мои типы, webpack все равно дал module not found: can't resolve @foo/bar.Так почему, чёрт возьми, вебпак не может его найти?Опять же, я нашел флаг, который мог бы показать мне больше:
webpack --verbose
Но здесь мне повезло меньше, поскольку правила веб-пакета были похожи на правила машинописи для разрешения модулей.Однако из вывода --verbose я заметил, что одним из файловых веб-пакетов был файл node_modules/@foo/bar/index.js.Тем не менее, в модуле bar не было никакого index.js, так как он был на самом деле просто пустым вложенным модулем вокруг таких подмодулей, как @ foo / bar / X.Является ли это ошибкой или функцией веб-пакета, я не знаю, но добавляю пустой файл index.js в пакет_узлов / @ foo / bar, и мой простой пример теперь работает с компонентом X, отображаемым в браузере при загрузкеHTML-страница.