[PR WELCOME] Discover primary and secondary entry points from user configuration

[dherges]

Type of Issue

[ ] Bug Report
[x] Feature Request

Description

Historically, a package.json and a ng-package.json are used to "configure" ng-packagr. The package.json is used for the module ID, npm metadata, and more node/npm-related things. The ng-package.json is used for destination paths, finding the entry file of an entry point, and angular/typescript/rollup-specific things.

Entry point discovery should be changed, see below. Discovery of primary and secondary entry points should both use this.

Expected Behaviour

New Draft / Outline (first one "wins"):

• package.json: ngPackage
• ng-package.json (requires a package.json as sibling)
• ng-package.js (default export, requires a package.json as sibling)

Note: ignore package.json w/o ngPackage property.

Version Information

ng-packagr: v2.0.0-rc.0

[DavidParks8]

I like this idea. If we implement it, then we should probably release a 1.x version which has a deprecation warning when it's used with ng-package.json.

[dherges]

One aspect makes me feel a little doubtful: it feels like polluting everything with pom.xml - just the name is now package.json. Technically, for npm, it would encourage to produce a lot of "invalid" package.json files (files w/o name, version, and so on...).

Haven't tried ... what happens when cd path/to/some/package-json && npm install?

[DavidParks8]

Also, I didn't document it, but ng-package.json should work as a marker for the creation of a secondary package as well. I don't know if that changes anything. Time for work! I'll check the npm sub install thing later.

[dherges]

For the primary entries in a "monorepo project" with multiple packages, I added "scripts": { "preinstall": "exit 1" } in each package.jsonto preventnpm install/yarn installin the subfolders. So I don't know what happens with emptypackage.json` files at all.

I am also interested how the npm teams sees the matter of putting multiple package.json files in one project ... have not any info for the moment though. Is there some blog post, issue discussion or similar docs on it?!?

[DavidParks8]

I just found https://stackoverflow.com/questions/10065564/add-custom-metadata-or-config-to-package-json-is-it-valid in support of custom package.json fields, but the more I think about it, the more I want to preserve both configuration methods. People are opinionated and like to choose for themselves how they configure things, and forcing them into one configuration method might make many unhappy.

[deebloo]

hmm im not sure about deprecating a separate config file. It isn't unusual for projects to have multiple options so why not just support both. If anything I would argue for also supporting
ng-package.js as well.

[dherges]

The initial design doc is a good starting point for discussion. Back then, I wrote that:

ng-package.json is a declarative way of describing an Angular library.

I would like to keep the declarative way but understand that sometimes you like to have "dynamic" configuration.

Right now, I would prefer

1. package.json: ngPackage field
2. ng-package.json
3. ng-package.js (with module.exports = { .. } or export default { .. }, i.e. foo = require('./ng-package'))

The custom "ng-package" would still have the limitation that it must be located in the same folder (next to) the package.json.

I will think about it a little more. I think that a 1.x feature release for the above change is a good idea. Then later, let's see whether to deprecate "old" ways of configuring. I'd like to maintain the goal of minimize amount of configuration (this also applies for things like configuration merging imho)

[dherges]

Related from #190: how should customization of primary and secondary entrypoints be handled? Should there be package.json, ng-package.json, and ng-package.js per sub-package? Should sub-packages be declared in one file (just the primary)?

[gnomeontherun]

I personally don't like adding stuff into package.json files. I don't have a problem with specific files for specific tools, because things stay organized and don't overload another file.

Having a ng-package.js type config file would be great should there be a need to write configuraiton/plugin type values, like what webpack does. For example, what if I wanted to write additional logic to copy files or something pre/post bundling, perhaps you could provide hooks during the build lifecycle to run tasks. Just a thought.

[DavidParks8]

Moving this to the more appropriate discussion here:

I propose we make this feature more configurable. We could offer 3 options for secondaries.

"secondaryEntrypoints": "none" // this would be the default
...
"secondaryEntrypoints: "automatic" // this would mimic the behavior in 1.5.0
...
"secondaryEntrypoints: ": [  // this would behave as you've described
   { 
     "name": "bar",  // I'm not sold on this field because the name must match the folder paths in dist, and it may cause complications and undesired behaviors. 
     "entryFile": "bar/public_api.ts" // If we require this to be a subfolder (like the automatic behavior) then we could easily generate package names
   }, 
   { 
     "name": "baz", 
     "entryFile": "baz/public_api.ts" 
   }
]

With such configurability, people can choose to implement their libraries in the way they want.

[github-actions]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

_{This action has been performed automatically by a bot.}