I'm trying to make a simple GET request using OAuth 2.0 and grant_type: 'client_credentials' but i keep getting an error. I followed the readme doc to initialize and make a request like below.

const FuelRest = require("fuel-rest");

const options = {
  auth: {
    clientId: "CLIENT_ID_HERE",
    clientSecret: "CLIENT_SECRET_HERE",
    authUrl:
      "https://MY_AUTH_URL.auth.marketingcloudapis.com/v2/token/", //Tried without '/v2/token/' also
  },
  origin: "https://MY_ORIGIN.rest.marketingcloudapis.com/",
};

const RestClient = new FuelRest(options);

const getOpts = {
  uri: "/platform/v1/endpoints",
  headers: {},
  // other request options
};

RestClient.get(getOpts)
  .then(function (response) {
    var result = response && response.body ? response.body : response;
    console.log(result);
  })
  .catch(function (err) {
    console.log(err);
  });

Error i am getting is

{ Error: No access token
    at AuthClient.getAccessToken.then.tokenInfo (E:\Development\node-scripts\node_modules\fuel-rest\lib\fuel-rest.js:88:18)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:189:7)
  res:
   { error: 'unsupported_grant_type',
     error_description: 'Use "authorization_code" or "refresh_token" or "client_credentials" or "urn:ietf:params:oauth:grant-type:jwt-bearer" as the grant_type.',
     error_uri: 'https://developer.salesforce.com/docs' } }

I hope i am initializing the client correctly for my use case.

https://github.com/salesforce-marketingcloud/FuelSDK-Node-Auth/wiki/isExpired
Github Wiki isExpired() true & false need to be swapped around..

Looking at the function the documentation should convey that:
if isExpired() returns true = token is expired or blank.
if isExpired() returns false = token is still valid

FROM

getAccessToken( requestOptions, forceRequest, callback )

TO

getAccessToken( options, callback )

options would have options.request and options.force.

Changing it to this would allow us to check the first argument and if it's a function it's the callback, otherwise it's options and use them. So we could do

getAccessToken( function( err, body ) {});

OR

getAccessToken( options, function( err, body ) {});

Fuel rest is moving to bluebird, so let's keep consistent

will make notifying clients easier, and we will have less callback "hell"

Need to have a better layout for docs/readme. Want to add methods and all available options.

At the moment, the promise is only rejected/callback returns error if the request module returns an error.

This should change to follow more with the API, having only 200 statuses resolve/callback success, and all others reject/callback error

Introduction:
Hello! I am just starting out with integrating with SFMC for my company and I am trying to use this SDK along with FuelSDK-Node-REST. At the start I am just trying to understand the best ways I can use these SDKs.

Task:
Easily Initialize this class for use. At the moment I feel like I'm really doing some wonky things to be able to make this Class work how I need it to. I think the root of my issues come from this class seems to be set up to work with the /v1/requestToken route for authentication, but I do not have a legacy package as such I need to be able to use /v2/token and the syntax between these to varies. Through a lot of digging into how the code works and lots of trial an error I can use the /v2 route.

My usage:
To just have a simple initialization process this how I get getAccessToken to work.

// Simple Initialization 
const options = {
  clientId: myClientId,
  clientSecret: myClientSecret,
  authUrl: authUrl // https://YOUR_SUBDOMAIN.auth.marketingcloudapis.com/v2/token
}

const AuthClient = new FuelAuth(options)
const authOptions = {
      force: true,
      json: {
        grant_type: 'client_credentials',
        client_id: myClientId,
        client_secret: myClientSecret
      }
    }
    AuthRest.getAccessToken(authOptions)
      .then(resp => {
           // I can see a valid response and my access token is under access_token
      })
      .catch(err => {
          // handle error
      })

If I wanted to make sure not to pass any options to getAccessToken, then this is what I did to get it to work.

// Complicated Initialization 
const options = {
  clientId: myClientId,
  clientSecret: myClientSecret,
  authUrl: authUrl, // https://YOUR_SUBDOMAIN.auth.marketingcloudapis.com/v2/token
  globalReqOptions: {
    json: {
      grant_type: 'client_credentials',
      client_id: myClientId,
      client_secret: myClientSecret
    }
  }

const AuthClient = new FuelAuth(options)
    AuthRest.getAccessToken()
      .then(resp => {
           // I can see a valid response and my access token is under access_token
      })
      .catch(err => {
          // handle error
      })

The Observation:
The module needs to be updated to be able to fluidly use both routes without much change to the client using this already. I think by changing the format of options in the constructor or even how the request calls are made will help make this more user friendly. I also think it should give a standard response to whoever is asking for the token. (I have some understanding how the base class is working, so I am also trying to think of the best way to achieve this.)

Takeaway:
The way things are now really do not allow for me to use FuelSDK-Node-Rest fluidly as I would like. The fact that FuelSDK-Node-Rest makes assumptions on the format of the response is where I am getting blocked. I cannot make any calls using the REST module since I get a Error: No access token which is happening because of how that code is looking for the access token. It expects accessToken and since v2 returns access_token that check for the token fails.

Hoping to get more insight on this!

Regards

should we pursue a feature where we allow the client to be initialized via a JWT? Might be useful if we have people set up in app center

I see we have a getAccessToken, and I haven't tested if I can do it with this implementation, but I know that we have customers and developers who are going to want to be able to instantiate this module and implement a long lived token feature...with minimal effort.

update deps

What license does this need to have?

Based on Alex's suggestion, should we pull the requesting mechanisms from this library? Should we pull it all together, or just the SOAP/REST requests, leaving the generic "request" functionality? Thoughts?