Updating to `apollo-angular@3.0.0` produces `error TS2307: Cannot find module 'apollo-angular/types' or its corresponding type declarations.`

Describe the bug Release 3.0.0 introduces an undocumented breaking change by moving the import location of types from apollo-angular/types to apollo-angular/build/types or apollo-angular/src/types.

To Reproduce Update an angular-apollo@2.x.x project importing types, such as import { QueryOptionsAlone, SubscriptionOptionsAlone, WatchQueryOptionsAlone } from 'apollo-angular/types';.

Expected behavior The import location should not change or the Migration Guide should specify the new import location.

Environment:

├── @angular/cli@13.2.4 
├── UNMET PEER DEPENDENCY @angular/core@13.2.3 
├── @apollo/client@3.5.9 
├── @types/graphql@14.5.0
├── apollo-angular@3.0.0 
├── barrel-maintainer@1.5.3
├── graphql@16.3.0 
└── typescript@4.5.5 

Additional context Thanks for the new release!

[kamilkisiela]

These sub-packages are fine, these are public as well, take for example apollo-angular/http. It’s documented, it’s designed to be used this way.

I will create a Pull Request to export *Alone options and all these 2nd level types in apollo-angular.

[KeithGillette]

Thanks for your detailed explanations, @kamilkisiela. I see your distinction that the shape of QueryOptionsAlone is public but the name and location of the particular type QueryOptionsAlone interface is private, or at least less public. As a library producer/maintainer, I can see why you might want to treat it as such. I hope you can appreciate why, as library consumer, I may want such second-level types to be public so I can easily reuse them to annotate my own code. From a consumer perspective, I see a big difference between the second level of parameter and return types and a third level of interior types not directly connected to any public API. Clearly the third level of private objects and their typings unconnected to the public API is none of my business. However, since the second level is tied directly to the public API in typing parameters and return types, I think a reasonable argument can be made for them to be part of the public API (and am curious how much of them not always being treated as such is an artifact of ECMAScript not supporting types natively and TypeScript layering on an optional type system). For what it’s worth, I’m used to importing such second-level typings from other TypeScript libraries, notably those that this one unites, @angular and @apollo/client, both of which export parameter and return type typings in their subpackages, though perhaps they are not technically considered public in those libraries, either.