v2.0.0 checklist

a list of breaking changes that we could group together. feedback welcome.

• drop the ‘r’ from arcgis-rest-geocoder?
• drop the ‘s’ from arcgis-rest-items?
• drop the ‘s’ from arcgis-rest-groups?
• rename arcgis-rest-common-types to arcgis-rest-common and move the growing collection of shared utility methods in request (that aren’t actually needed by request) there along with the types
• getAsyncStuff> fetchAsyncStuff? (and use get for getters instead)
• consolidate feature-service and feature-service-admin
• start bundling common inside upstream packages?
• keep documenting the structure, but stop declaring a named interface, for unique responses.
• remove serviceInfo() from arcgis-rest-geocoder
• esriGeometryType > GeometryType
• esriUnits > Units
• esriFieldTypes > FieldTypes
• folder > folderId in IItemCrudRequestOptions (see #236)
• fix capitalization of IOauth2Options (to be IOAuth2Options)
• replace "adds"/"updates"/"deletes" in feature service crud functions with consistent use of "features"
• remove appendCustomParams() re-export from feature-service (see #365)
• change signature of getItemResources() (for consistency)
• remove IGeocodeParams #468
• remove serializeGroup()#475
• remove IItemResourceAddRequestOptions
• consolidate items, groups, sharing and users packages into @esri/arcgis-rest-portal
• IParamBuilder / SearchQueryBuilder
• rename common-types to types and rexport typings, make it a real dep, and rexport interfaces and types from dependent packages
• move getPortalUrl() and getPortal() from request to portal
• move getUserUrl() from auth to portal
• change signature of appendCustomParams
• add withOptions() and setDefaultOptions() to request
• make signatures of searchItems() and searchGroups() consistent #104
• generateToken(optionsOrParams) > generateToken(options) (see: https://github.com/Esri/arcgis-rest-js/pull/264#discussion_r208381410)
• geocoder > geocoding @tomwayson
• feature-service > feature-layer (@tomwayson)
• feature-service-admin > service-admin (@tomwayson)
• re-exporting types in upstream packages (@patrickarlt)
• standardize exported constants (@patrickarlt)
• ICustomeRequestOptions > ICustomOptions @tomwayson

[tomwayson]

Before we go to 2.0 I’d like to at least discuss consolidating all the “portal” packages - items, groups, sharing, users, etc, are all so intertwined that even if you start out only using 1 or 2 of them, you’ll eventually end up using most of them. I think it’d be a lot simpler if those were all in @esri/arcgis-rest-portal (or -sharing, or whatever). Now that modern apps can treeshake our packages (#490), we can stress less about bundling too much code.

[itrew]

we’re not manipulating any interfaces or types from @esri/arcgis-rest-types in any other packages. i don’t think there’s any need to be concerned about transitive dependencies changing from underneath you because lerna is going to bump the underlying dependent version of types in every other package automatically in each release to keep it in sync.

I didn’t mean to imply you were, I more meant it would be nice to have those re-exported modules documented as well (at least that it’s coming from -types).

we don’t have any need to import/re-export Webmap in any other package at the moment. If it would be helpful for you if Webmap was added as a submodule within types to document types that extent their counterpart outside of webmaps would be helpful, i’d be happy to try and help you (or anyone else) land a PR.

This was just an option try and keep things clean, not really a requirement of mine. Right now, this library has types from both specs intermingled (e.g. IField is from the webmap spec, IFeatureSet is from common). Now probably 95% of the time that won’t be an issue, so it probably won’t be an issue and can wait. Down the road though I’d be happy to assist with any typings.