Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: How to make library with multiple entry points? #12

Open
jbeckton opened this issue Oct 20, 2017 · 2 comments
Open

Question: How to make library with multiple entry points? #12

jbeckton opened this issue Oct 20, 2017 · 2 comments

Comments

@jbeckton
Copy link

I am using your seed for a library I am building that is going to be kind of large. I am trying to set up my library source so that I can have multiple entry points like...

@mylib/security
@mylib/logging
@mylib/ui
...

This way consumers of the lib will be able to import modules and components from the appropriate location in the library.

@ShaneYu
Copy link

ShaneYu commented Nov 8, 2017

Perhaps you could take a similar approach to what ng-bootstrap did? You can import the entire log via the NgbModule or import individual modules. Tree shaking will do the rest.

https://github.com/ng-bootstrap/ng-bootstrap/tree/master/src

@Kamilius
Copy link

Kamilius commented Nov 9, 2017

@jbeckton Based on angular-library-seed (which was already mentioned by @ShaneYu), I'm developing two kinds of things:

  • common-ui kit for our organization, actually based on approach taken by ng-bootstrap, which really works.
  • feature-module-seed - seed project for a isolated features with their own imbedded routing and resources. In advance they are just being imported into a root project application. This really gives an ability to develop big features by different teams and not impacting main application directly. Even though those features are living (being rendered and functioning) as a part of a main project application. This one's also utilizing an approach of ng-bootstrap.

Basically, whole idea is based on module per component, and a '.forRoot()' convention. Which in advance helps to successfully tree shake unused stuff via webpack or a rollup.

Don't include library scripts as a separate files. Just npm/yarn add a whole library, use only things you need and - treeshake unneeded during prod build.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants