Библиотека angluar-cli создает вторичную точку входа

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

@scope/data-service
@scope/data-service/models

Использование angular-cli для генерации базового пакета генерирует следующую структуру

scope
└───data-service
    │   karma.conf.js
    │   ng-package.json
    │   ng-package.prod.json
    │   package.json
    │   tsconfig.lib.json
    │   tsconfig.spec.json
    │   tslint.json
    │
    └───src
        │   public_api.ts
        │   test.ts
        │
        └───lib
                data-service.component.spec.ts
                data-service.component.ts
                data-service.module.ts
                data-service.service.spec.ts
                data-service.service.ts

Основываясь на документации ng-packagr, вы добавляете папку в data-service под названием models, затем добавляете вторую package.json в эту папку, но ng-packagr, похоже, использует немного другую структуру, чем angular-cli. В идеале я пытаюсь смоделировать структуру, аналогичную https://github.com/angular/angular/tree/master/packages/common но до тех пор, пока @scope/data-service а также @scope/data-service/models Я был бы счастлив.

Когда я пытаюсь создать структуру, аналогичную рекомендации ng-packager, я получаю

error TS6059: File 'C:/projects/data-service-app/projects/scope/data-service/models/src/index.ts' is not under 'rootDir' 'C:\projects\data-service-app\projects\scope\data-service\src'. 'rootDir' is expected to contain all source files.

Когда я перемещаю каталог моделей в data-service\src каталог мои точки входа

@scope/data-service
@scope/data-service/src/models

Как мне избавиться от src на моей вторичной точке входа?

Каков правильный подход к созданию библиотеки с дополнительной точкой входа при использовании angular-cli?

2 ответа

Спасибо за ответ. Вот решение, которое я выбрал, все вращалось вокруг правильной настройки файлов index.ts и public_api.ts

\---projects
    \---scope
        \---ngx-package
            |   karma.conf.js
            |   ng-package.json
            |   ng-package.prod.json
            |   package.json
            |   tsconfig.lib.json
            |   tsconfig.spec.json
            |   tslint.json
            |
            \---src
                |   public_api.ts
                |   test.ts
                |
                +---lib
                |       package-client-config.ts
                |       package-client.spec.ts
                |       package-client.ts
                |       package.module.ts
                |
                \---models
                    |   index.ts  (1)
                    |   package.json (2)
                    |   public_api.ts  (3)
                    |
                    \---src
                        |   public_api.ts  (4)
                        |
                        \---lib
                            |   model-a.ts
                            |   model-b.ts
                            |
                            \---hateoas
                                    hateoas.ts

Хорошо, так что в дереве выше отмечает паренсы с номерами внутри, они соответствуют файлам ниже.

1) /projects/scope/ngx-package/src/models/index.ts

// export what ./public_api exports so we can reference models like
// import { modelA } from './models'
export * from './public_api';

2) /projects/scope/ngx-package/src/models/package.json

{
  "ngPackage": {}
}

3) /projects/scope/ngx-package/src/models/public_api.ts

export * from './src/public_api';

4) /projects/scope/ngx-package/src/models/src/public_api.ts

export * from './lib/model-a';
export * from './lib/model-b';
export * from './lib/hateoas/hateoas';

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

Я боюсь, что это не простая задача с ng-packagr.

Для каждого "проекта", который вы пытаетесь упаковать, ng-packagr автоматически обнаруживает все вторичные пакеты.

нг-пакагр игнорирует tsconfig.lib.json файлы вторичных пакетов, он будет использовать файл tsconfig, предоставляемый с первичным пакетом.

Затем он загружает программу TS для первичного и всех вторичных серверов перед компиляцией с помощью tsconfig первичного.

Это делается таким образом, чтобы упаковщик мог затем проанализировать код и создать дерево зависимостей, которое сообщит ему, какой пакет визуализировать первым, вторым и т. Д.... ДА, это также означает, что ng-packagr НЕ ПРЕДЛАГАЕТ, что вторичный пакет всегда зависит от основного, это может быть другой путь, и это действительно...

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

Ошибка, которую вы видите, возникает на этапе компиляции, когда компилятор пытается выдавать файлы и генерирует файлы. Это когда ng-packagr регистрирует "Компиляция источников TypeScript через ngc"

На этом этапе машинопись не устраивает ссылку на файл вне корня, что имеет место.

Одним из решений является обновление paths недвижимость в tsconfig указывать на выходной каталог для каждого пакета, который был собран. Так что, если пакет A был только что скомпилирован, мы меняем / создаем paths запись, которая указывает на выходную библиотеку, которая не будет рассматриваться как источник TS... таким образом, нет ошибки.

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

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

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

Пример макета папки для дополнительных точек входа

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

my_package
├── src
|   ├── public_api.ts
|   └── *.ts
├── ng-package.json
├── package.json
└── testing
    ├── src
    |   ├── public_api.ts
    |   └── *.ts
    └── package.json

Содержание my_package/testing/package.json может быть таким простым, как:

{
  "ngPackage": {}
}

No, that is not a typo. No name is required. No version is required. It's all handled for you by ng-packagr! When built, the primary entry point is imported by import {..} from '@my/library' and the secondary entry point with import {..} from '@my/library/testing'

Source - https://github.com/ng-packagr/ng-packagr/blob/master/docs/secondary-entrypoints.md

Другие вопросы по тегам