Как изменить структуру сборки библиотеки Angular 10
Я поддерживаю библиотеку Angular 10 Ivy и пытаюсь обновить ее, чтобы использовать вторичные точки входа, но у меня возникают проблемы со структурой папок окончательной сборки.
В идеале структура папок должна эмулировать структуру папок @angular:
-node_modules
|
-- @angular
|
--core
--common
--cli
--material
...
и я мог бы импортировать части библиотеки, например: import { someModule } from '@angular/core';
Моя текущая библиотека построена со структурой папок
-node_modules
|
--myLibrary
|
--package.json
--dist/myLibrary
|
--package.json
--public_api.ts
--myLibrary.d.ts
--feature1
--feature2
--feature3
...
что заставляет меня импортировать такие функции, как import { feature1Module} from 'myLibrary/dist/myLibrary/feature1';.
Я знаю, что могу удалить вторую папку myLibrary, обновив путь dest в моем myLibrary/ng-package.json, но я не знаю, как удалить папку dist, чтобы все строилось на одном уровне, так как настройка "dest": "../.." не будет строиться.
{
"$schema": "../../node_modules/ng-packagr/ng-package.schema.json",
"dest": "../../dist/myLibrary",
"assets": [
"quill/*.scss"
]
}
Любая помощь приветствуется.
Обновлять: Структура проекта
-projects
|
--myLibrary
|
--package.json
--ng-package.json
--src
|
--public_api.ts
--commonFunctions
--feature1
|
--package.json
--src
|
--public_api.ts
--index.ts
--feature1.component.ts
--feature1.component.html
--feature1.module.ts
--feature2
--feature3
...
Мой projects/myLibrary/src/public_api.ts экспортирует только функции в commonFunctions, а каждый из файлов public_api.ts в каждой из папок функций экспортирует только модули и компоненты соответствующих функций.
Нет, feature1 экспортируется только через собственный файл public_api.ts. Насколько я понимаю, если функция 1 была экспортирована из основного файла библиотеки public_api.ts, то функция 1 всегда будет импортирована в проект-потребитель, независимо от того, действительно ли этот проект использовал функцию 1. Это противоречит цели использования вторичных точек входа.
В случае angular каждый @angular/* — это отдельный пакет. Если вы доставляете несколько пакетов через my-package/pkg1, вы можете получить такую структуру папок. Не иначе. Также не имеет смысла иметь такую структуру, кроме как собрать несколько пакетов собственного производства в одном месте.
@Сергей, спасибо за ответ! Пожалуйста, загляните в библиотеку @angular/material. Моя конечная цель — разрешить импорт из myLibrary/feature1, аналогично тому, как @angular/material разрешает импорт из @angular/material/buttons. Прочитав документацию в ng-packagr на вторичных конечных точках, это должно быть возможно (github.com/ng-packagr/ng-packagr/blob/master/docs/…)
Ответы 2
У меня аналогичная структура папок, в моей библиотеке есть Input, Button... и т. д., которые называются функциями, как вы сказали. И в ng-package.json у меня есть настройки, как показано ниже:
{
"$schema": "../../node_modules/ng-packagr/ng-package.schema.json",
"dest": "../../dist/ngx-pluto",
"lib": {
"entryFile": "src/index.ts",
"cssUrl": "inline"
}
}
И в моей функции table.module.ts я могу импортировать функцию NpPaginatorModule, как показано ниже:
import { NpPaginatorModule } from '../paginator/index';
И после того, как я использую npm для публикации своей библиотеки, я могу импортировать свою функцию в свой потребляющий проект, как показано ниже:
import { NpButtonModule } from 'ngx-pluto';
Вот моя ссылка на код только для справки: https://github.com/KevinZhang19870314/pluto-ui
Привет, Кевин, я ценю твой ответ, но твоя библиотека имеет только одну точку входа и, к сожалению, мне не помогает. Проблема, с которой я сталкиваюсь, является результатом переноса моей библиотеки на использование вторичных точек входа, которые делают функции моей библиотеки древовидными. В вашей библиотеке, если потребляющее приложение использует только вашу функцию «кнопка», оно по-прежнему импортирует все остальные функции в вашей библиотеке. В моем случае это плохо, поскольку некоторые из моих функций имеют большие сторонние зависимости, которые я бы предпочел не загружать потребляющим приложением, если оно не использует эту функцию.
Нет-нет, в моей библиотеке, если вы хотите использовать только «Кнопку», вам просто нужно импортировать NpButtonModule, никаких других модулей импортировать не нужно. Вот почему я показал эти элементы управления. И если у вас есть некоторые сторонние зависимости, вам нужно импортировать их в свою конкретную функцию, и эти сторонние зависимости будут использоваться как связанные зависимости в файле package.json вашей библиотеки (например, github.com/KevinZhang19870314/pluto-ui/ blob/master/projects/…). Когда вы создаете потребляющее приложение с установленной библиотекой, я думаю, что только импортированная функция будет связана с angular cli.
Ваша библиотека на самом деле не является древовидной. Взгляните на свой файл public-api.ts (github.com/KevinZhang19870314/pluto-ui/blob/master/projects/…). Это заставляет вашу библиотеку постоянно делать все ваши функции доступными для потребляющего приложения. Если бы вы могли использовать динамический импорт, технически вы могли бы обойти большие сторонние зависимости, сделав их необязательными зависимостями и не добавляя их в приложение-потребитель, но у меня нет такой роскоши, потому что я должен поддерживать IE11, а ES5 не имеет динамического импорта. .
Здесь эта статья может помочь объяснить вторичные точки входа лучше, чем я могу в комментарии. medium.com/tunaiku-tech/…
Это решает вашу проблему?github.com/ng-packagr/ng-packagr/issues/…
Я нашел ответ на свой вопрос.
Моя проблема в том, что я импортирую свою библиотеку в свои проекты как зависимость от github, а не как пакет npm. Я делаю это, потому что Github позволяет пользователям бесплатно размещать частные репозитории, но NPM требует платной ежемесячной подписки на частные пакеты, поэтому обходной путь нашей компании состоял в том, чтобы добавить зависимость нашей частной библиотеки, например "my-library": "git+ssh://[email protected]/myOrg/my-library.git#semver:10.2.7". Это на самом деле работает, когда вы не реализуете вторичные точки входа, поскольку ваша первичная точка входа указывает на файл определений, который создается со всеми функциями библиотеки и имеет надлежащие указатели на эти функции.
Структура встроенного модуля становится проблемой, когда вы пытаетесь внедрить вторичные точки входа, поскольку ng-packagr не проходит более чем на один уровень вниз в структуре вашего модуля при поиске дополнительных файлов package.json, которые обозначают вторичные точки входа. После прочтения https://github.com/npm/npm/issues/2974 кажется, что npm не поддерживает установку проектов из подкаталогов, а вместо этого просто ищет первый package.json файл, который находит в репозитории, и устанавливает его. как модуль. Это то, что дает мне странную структуру папок, поскольку репозиторий на самом деле представляет собой монорепозиторий, в котором размещается моя библиотека, демонстрационный проект и проект тестирования e2e. Поскольку нет поддерживаемого способа установить только один из этих проектов по отдельности, мои возможные решения ограничены либо разбиением библиотеки на собственный репозиторий Github, либо написанием скрипта postinstall, который будет копировать/вставлять содержимое node_modules/myLibrary/dist/myLibrary в node_modules/myLibrary
похоже, что сценарии постустановки на самом деле не работают с окнами прямо сейчас, поскольку npm запускает свой сценарий постустановки в appdata/roaming, а не в реальном проекте, в котором выполняется установка npm. К сожалению, решение состоит в том, чтобы разместить частный репозиторий github, который является просто артефактом сборки из библиотеки.
Экспортируется ли функциональный модуль 1 из общедоступного API библиотеки? Если да, может ли это быть просто импорт, например, import { featuremodule1 } из «моей библиотеки»? Это похоже на то, как вы импортируете основные модули angular, такие как httpclient, из некоторого пути dist.