Is my definition of dependencies consistent?

I am helping Okta to refresh the code and the text of some important blogs/tutorials (besides being a good guy, I am also interested in referring these tutorials to people interested in Okta :wink:

I am trying to make the https://github.com/oktadeveloper/okta-node-express-example to work with the current versions of libraries:

"dependencies": {
    "@okta/oidc-middleware": "^4.0.1",
    "@okta/okta-sdk-nodejs": "^4.1.0",
    "cookie-parser": "~1.4.5",
    "debug": "~4.1.1",
    "dotenv": "^8.2.0",
    "express": "~4.17.1",
    "express-session": "^1.17.1",
    "hbs": "~4.1.1",
    "http-errors": "~1.8.0",
    "lodash": "^4.17.20",
    "morgan": "~1.10.0",
    "nodemon": "^2.0.4"
  },

The invocation of the OIDC constructor:

const oidc = new ExpressOIDC({
  issuer: `${process.env.ORG_URL}/oauth2/default`,
  client_id: process.env.CLIENT_ID,
  client_secret: process.env.CLIENT_SECRET,
  redirect_uri: `${process.env.HOST_URL}/authorization-code/callback`,
  scope: 'openid profile',
})

results with the Error: Your appBaseUrl is missing.

Internet searches result with the advice to “downgrade” @okta/oidc-middleware - and I am doing this work just so this advice becomes redundant.

Can some good soul tell me how to modify my dependencies version numbers, so that I build a state of the art of the of this app, please?

but it seems in the documentation there is a parameter appBaseURL to initialize your OIDC MW - https://github.com/okta/okta-oidc-js/tree/master/packages/oidc-middleware#usage-guide

Thank you, @phi1ipp your observation is correct.

My constructor settings come from a two-year-old app written by a member of the Okta team, so at that time the appBaseUrl argument was not required nor expected. So, my question is a bit more generic, hoping for a document that defines the constructor (or API) arguments as a function of the version of libraries as the function of the library versions.

Even better (more useful) would be information on the compatibility of the Okta libraries version with other version numbers that appear in the dependencies list being a part of package.json. Such consistency checks (say implemented as plugins to Visual Studio code) would be a terrific contribution to the set of “pedestrian” tasks we have to go through at this time.