#javascript #angular #typescript #frameworks #systemjs
#javascript #angular #typescript #фреймворки #systemjs
Вопрос:
Я разрабатывал фреймворк, опубликованный в NPM, и все работало нормально. Но что-то действительно болит, когда я использую свой собственный фреймворк в качестве внешнего модуля. Я должен установить импорт с полными путями, подобными этому :
import { MyService } 'myframework/all/the/internal/path/myservice.service';
И я должен создать одну отдельную инструкцию импорта для каждого класса, службы или веб-компонента, которые я использую в своем фреймворке. Я полагаю, это связано с тем, что файлы объявлений не экспортируются из верхнего файла index.d.ts.
Благодаря Matthias247 я правильно написал файлы реэкспорта, в которые я экспортирую все классы в моем фреймворке. И при использовании его в качестве внешнего модуля NPM он работает хорошо, и я могу писать все импортируемые файлы таким образом :
import {MyService, MyClass1, MyClass2, ... } from 'myframework';
Теперь, когда это работает, я попытался сделать мои скомпилированные файлы JavaScript единым bundle.js который будет загружен SystemJS точно так же, как модули @angular.
И вот тут я действительно совершенно потерялся… Я не могу понять, каков или должен быть правильный способ создания такого пакета. При использовании browserify каждая команда завершается ошибкой из-за записи «NO_MODULE_FOUND» в мой bundle.js . Итак, затем я попытался использовать tsify для запуска в качестве плагина browserify, и, похоже, он выполняет правильную работу, собирая все классы в один пакет. Но небольшая проблема, он также объединяет все @angular и RxJS.
Пожалуйста, кто-нибудь мог бы рассказать мне, как должен создаваться пакет UMD? Я компилирую с опцией «module: commonjs», но поскольку browserify распознает любой файл как модуль, я действительно не знаю, что делать.
Ответ №1:
Одно из возможных решений (и то, которое я предлагаю) — лучше настроить экспорт вашей библиотеки, чтобы вы могли делать
import {MyService, MyClass1, MyClass2, ... } from 'myframework';
в конце концов, даже несмотря на то, что эти типы могут быть определены во вложенной папке вашего фреймворка.
Обычный способ сделать это — использовать реэкспорты. В главной папке вашего фреймворка у вас может быть некоторый index.ts while, который повторно экспортирует все типы, которые допустимы для пользователя.
Нравится
export * from 'myframework/all/the/internal/path/myservice.service';
Чтобы не ссылаться на все типы из основного индексного файла, вы также можете сделать это иерархическим способом. Например. определите файл index.ts также во вложенных папках, например myframework/all/the/internal/path/index.ts , и экспортируйте в него все типы из этой папки. Затем на более высоком уровне экспортируйте вложенную папку: export * from 'myframework/all/the/internal/path';
Комментарии:
1. Что ж, я уже делаю это, как я объяснил. Моя проблема заключается в разрешении пути выполнения. При загрузке моего фреймворка в качестве модуля SystemJS он пытается импортировать в » host / myframework / dist «, и это не работает, я получаю 404, потому что он должен перейти в » host/myframework/dist/feature/feature.class » или что-то в этом роде.
2. Вы этого не делаете. Вы написали, что внедрили файл .d.ts, который изменит объявления, но не окажет влияния на экспортируемый код и загрузку среды выполнения. Я рекомендовал написать ts-файл (№ d), который реализует повторный экспорт. Это изменит сгенерированный код и устранит вашу проблему во время выполнения, поскольку при импорте основного индексного файла будут импортированы и остальные.
3. Действительно! На самом деле просмотр файлов node_modules / @angular / core index вводит меня в заблуждение, потому что они используют пакет umd и не нуждаются в тех же вещах, что и я. У меня уже был иерархический реэкспорт, как вы предложили, но я просто пытался использовать свои корневые поддельные индексные файлы (.d.ts и .js). Итак, теперь я использую свой основной index.js (сгенерированный из реального index.ts) из моей папки dist, и он работает во время выполнения. Большое спасибо ! 🙂 Но я все еще хотел бы понять, как сгенерировать пакет UMD с помощью browserify, поэтому я отредактирую свой вопрос и подожду, прежде чем отмечать ваш ответ как принятый.
4. Извините, но это совершенно другой вопрос. Вы не должны делать подобные вещи, а вместо этого задать другой вопрос, поскольку никто не сможет следить за вами, и это несправедливо по отношению к респондентам. Был дан ответ на первоначальный вопрос.
5. Ну … мой первоначальный вопрос был «Пожалуйста, не мог бы кто-нибудь подсказать мне, как должен создаваться пакет UMD?». И это все еще тот вопрос, на который я тоже хочу получить ответ. Но в моем посте было много чего, и вы исправили мою проблему во время выполнения, так что вы правы, я должен задать новый вопрос более конкретно о том, как сгенерировать пакет.