Epic: ArcGIS REST JS v5

[patrickarlt]

This issue is for discussing what should be included in ArcGIS REST JS v5 which be our next major version and breaking change opportunity.

There are a few things that we have already discussed:

• Node and browser support bumps Version and browser support updates #1187
• TypeScript 5 Version and browser support updates #1187
• Switch to Vitest for testing Version and browser support updates #1187 this seems to be the path that most teams inside Esri are going.

Currently that would be it. However I want to throw out a few more ideas:

• Move most request and fetch options to separate requestOptions (option flags used in our internal request function) and fetchOptions (options passed to the internal call to fetch). The only things I would keep would at the top level would be authentication and params. This would mean our main options interface looks like this:

  {
    params: any; // any additional params to append to the request
    authentication: IAuthenticationManager | string; // auth manager or access token
    requestOptions: { // additional options for our intenal request method
      hideToken: boolean; // put the token param in the header for GET requests
      suppressWarnings: boolean // silence all internal console warnings from REST JS 
      portal: string; // used internall by some requests to construct URLs, will override the portal set in thi authentication option
    };
    /** 
     * anything you can pass to the options for fetch 
     * https://developer.mozilla.org/en-US/docs/Web/API/RequestInit 
     * REST JS may override or ignore these as it sees fit. REST JS
     * currently modifies the headers and credentials options.
     **/
    fetchOptions: RequestInit 
  
  }

  This would make it so that we can easily copy options around inside higher level methods where we make multiple internal calls to different endpoints like createApiKey()
• Remove rawResponse as per discussion in Update typings for functions that wrap request() to return Response when using rawResponse #821 this might mean that some user might be disappointed like in solveRoute throws error when used with rawResponse #1045 (comment) because you wouldn't be able to access response headers. Could we solve this by appending headers to the responses?
• Support only Node 22+. This means we can ditch all the complexity with node-fetch and the extra packages and finally assume that a standard fetch exists everywhere. Maintenance on 18 ends in April 2025 (this year) and maintenance on 20 ends April 2026 so this might be a controversial move.