8000 Reduce peerDependencies · Issue #786 · Esri/arcgis-rest-js · GitHub
[go: up one dir, main page]

Skip to content
Reduce peerDependencies #786
@tomwayson

Description

@tomwayson

Currently just about every package has 2 peerDependencies: request and auth. In my experience peerDependencies are hard for people to grok/manage. Ideally we'd have it so that all packages only have a single peer dependency, which would be request.

First, I don't think any of these packages need to even declare a dependency (peer or otherwise) on arcgis-rest-auth (they never import from it):

  • arcgis-rest-feature-layer
  • arcgis-rest-geocoding
  • arcgis-rest-routing

We should remove those dependencies.

Second, arcgis-rest-service-admin only imports IUserRequestOptions from auth. We could move that interface to either the request or types package and drop the dependency on auth.

Side note, it looks like the types package is under dependencies of all the other packages, but it probably should be under devDependencies, right?

OK, finally, only the arcgis-rest-portal package actually imports a concrete implementation from auth, UserSession, but it only uses it type declarations (e.g. export function getUserUrl(session: UserSession): string). We can't move the UserSession class to the types package. We could move the dependency under devDependencies, but it would be up to us to make sure we don't introduce any runtime uses (like new UserSession()). Seems a bit risky. Maybe we just leave it as under peerDependencies in this case?

To me the only downside of moving away from having auth as a peerDependency is that we'll have to rely on the docs (alone) to get across the message that "You need to install @esri/arcgis-rest-auth if you need to make authenticated requests."

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

    0