https://github.com/adobe/aio-lib-core-logging

The devDependency @adobe/eslint-config-aio-lib-config was updated from 1.0.2 to 1.1.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@adobe/eslint-config-aio-lib-config is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

request-promise-native has a peer dependency on request. That dep should be specified in package.json.
https://github.com/adobe/aio-lib-core-ims/blob/291c0e567ebdde3df48b08c9ccf6ea661402f764/package.json#L10

Consider migrating to cross-fetch.

Describe the solution you'd like

getToken should optionally accept an options object that is aggregated with the context configuration and passed to the imsLogin method of the plugin.

Describe alternatives you've considered

adobe/aio-cli-plugin-auth#61

Additional context

adobe/aio-cli-plugin-auth#62
adobe/aio-lib-ims-oauth#43

(this is essentially the glue between them)

The protocol at https://www.adobe.io/authentication/auth-methods.html#!AdobeDocs/adobeio-auth/master/JWT/JWT.md does not require the technical account email but only the id. Therefore it is not necessary to maintain technical_account_email in the configuration.

Describe the bug
Running aio auth:ctx --list without configuration yields:

TypeError: Cannot convert undefined or null to object
    at Function.keys (<anonymous>)
    at CliConfig.contexts (/usr/local/lib/node_modules/@adobe/aio-cli/node_modules/@adobe/aio-lib-ims/src/config/cli.js:48:19)
    at Context.keys (/usr/local/lib/node_modules/@adobe/aio-cli/node_modules/@adobe/aio-lib-ims/src/context.js:189:25)
    at CtxCommand.run (/usr/local/lib/node_modules/@adobe/aio-cli/node_modules/@adobe/aio-cli-plugin-auth/src/commands/auth/ctx.js:22:38)
    at CtxCommand._run (/usr/local/lib/node_modules/@adobe/aio-cli/node_modules/@oclif/command/lib/command.js:44:31)

To Reproduce
Steps to reproduce the behavior:

1. Launch empty NodeJS 10 docker container: docker run --rm -it node:10-alpine /bin/sh
2. Clean install aio CLI version 3.2.0: npm install -g @adobe/aio-cli
3. Run aio auth:ctx --list
4. See error

Expected behavior
No output

Screenshots
n/a (see dump in the description)

Desktop (please complete the following information):

# aio -v
@adobe/aio-cli/3.2.0 linux-x64 node-v10.19.0

I tried getToken method of this lib in a Runtime action, but received an error. Code snippet:

const { context, getToken } = require('@adobe/aio-lib-ims')
const imsContextConfig = {
      client_id: params.clientId,
      client_secret: params.clientSecret,
      techacct: params.techAcct,
      meta_scopes: params.metaScopes,
      ims_org_id: params.orgId,
      private_key: params.privateKey
}
await context.set('my_ctx', imsContextConfig)
const token = await getToken('my_ctx')

This worked when I ran in local node environment, but when running in a Runtime action, it gave an error:

error: Cannot generate token because no plugin supports configuration

I enabled the debug logs in the lib by placing process.env.DEBUG='@adobe/aio-lib-ims*' in the first line of my action code (before requiring @adobe/aio-lib-ims), and this is what I got:

2020-04-23T09:56:05.280Z       stdout: 2020-04-23T09:56:05.280Z @adobe/aio-lib-ims/token-helper getTokenIfValid(token=undefined)
2020-04-23T09:56:05.281Z       stdout: 2020-04-23T09:56:05.281Z @adobe/aio-lib-ims/token-helper _generateToken(reason=Error: Token missing or expired, force=false)
2020-04-23T09:56:05.281Z       stdout: 2020-04-23T09:56:05.281Z @adobe/aio-lib-ims/context get plugins
2020-04-23T09:56:05.281Z       stdout: 2020-04-23T09:56:05.281Z @adobe/aio-lib-ims/config/cli set($plugins)
2020-04-23T09:56:05.281Z       stdout: 2020-04-23T09:56:05.281Z @adobe/aio-lib-ims/token-helper   > Trying: @adobe/aio-lib-ims-oauth/src/ims-cli
2020-04-23T09:56:05.290Z       stdout: 2020-04-23T09:56:05.290Z @adobe/aio-lib-ims/token-helper   > Ignoring failure loading or calling plugin @adobe/aio-lib-ims-oauth/src/ims-cli: { Error: Cannot find module '@adobe/aio-lib-ims-oauth/src/ims-cli' at webpackEmptyContext (/nodejsAction/XXpdBGPj/index.js:175400:10) at Object._generateToken (/nodejsAction/XXpdBGPj/index.js:156564:65) at process._tickCallback (internal/process/next_tick.js:68:7) code: 'MODULE_NOT_FOUND' }
2020-04-23T09:56:05.290Z       stdout: 2020-04-23T09:56:05.290Z @adobe/aio-lib-ims/token-helper   > Trying: @adobe/aio-lib-ims-jwt
2020-04-23T09:56:05.290Z       stdout: 2020-04-23T09:56:05.290Z @adobe/aio-lib-ims/token-helper   > Ignoring failure loading or calling plugin @adobe/aio-lib-ims-jwt: { Error: Cannot find module '@adobe/aio-lib-ims-jwt' at webpackEmptyContext (/nodejsAction/XXpdBGPj/index.js:175400:10) at Object._generateToken (/nodejsAction/XXpdBGPj/index.js:156564:65) at process._tickCallback (internal/process/next_tick.js:68:7) code: 'MODULE_NOT_FOUND' }
2020-04-23T09:56:05.290Z       stdout: 2020-04-23T09:56:05.290Z @adobe/aio-lib-ims/token-helper   > Trying: @adobe/aio-lib-ims-oauth
2020-04-23T09:56:05.290Z       stdout: 2020-04-23T09:56:05.290Z @adobe/aio-lib-ims/token-helper   > Ignoring failure loading or calling plugin @adobe/aio-lib-ims-oauth: { Error: Cannot find module '@adobe/aio-lib-ims-oauth' at webpackEmptyContext (/nodejsAction/XXpdBGPj/index.js:175400:10) at Object._generateToken (/nodejsAction/XXpdBGPj/index.js:156564:65) at process._tickCallback (internal/process/next_tick.js:68:7) code: 'MODULE_NOT_FOUND' }

Is your feature request related to a problem? Please describe.

This library (and aio-lib-ims-jwt and aio-lib-ims-oauth although I'm not yet creating separate issues for those since I'd like to get consensus on this library first) creates Error objects which are hard to distinguish in a programatic way from generic JavaScript Error objects.

Describe the solution you'd like

Errors thrown should use @adobe/aio-lib-core-errors to produce errors with a populated name and sdkName properties specific to this library.

Describe alternatives you've considered

• Parsing the error message
• Inspecting the stack trace

Neither of which are really scalable.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug

After logout a user should be able to login again into a different org.
Instead, the org selection step is skipped in the browser unless the user explicitly cleans the Adobe cookies.

Describe the bug

The Ims.validateToken method passes the wrong field, token_type, instead of type to the IMS API. This causes certain JWTs to be rejected.

To Reproduce

Steps to reproduce the behavior:

1. Go to https://console.adobe.io
2. Create a new integration
3. Use the private key and related information to create a JWT
4. Pass this JWT to the Ims.validateToken API

Expected behavior

The call should succeed, but it fails with this error:

400 - {"error_description": "Type parameter is required!", "error": "invalid_parameter_value"}

Expected Behaviour

If I set a local context the access_token should be stored in local config file .aio

Actual Behaviour

local context get rewritten to global config and access_token is stored there

Reproduce Scenario (including but not limited to)

If a user has access to multiple programs he cannot switch the programs as long as the old access_token is stored in the global config file. This is irritating when a local config has been setup

Steps to Reproduce

Create a local config for programA with

aio config:set ims.contexts.aio-cli-plugin-cloudmanager PATH_TO_CONFIG_JSON_FILE --file --json --local
aio config:set ims.contexts.aio-cli-plugin-cloudmanager.private_key PATH_TO_PRIVATE_KEY_FILE --file --local

execute a command within /programmA

aio cloudmanager:list-programs

check for the access_token in .aio

Platform and Version

❯ aio info                                                                                                                                                                                      18:25:30

  System:
    OS: macOS 11.2.2
    CPU: (4) x64 Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
    Memory: 24.42 MB / 8.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 12.20.1 - ~/.nvm/versions/node/v12.20.1/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 6.14.10 - ~/.nvm/versions/node/v12.20.1/bin/npm
  Virtualization:
    Docker: 20.10.5 - /usr/local/bin/docker
  npmGlobalPackages:
    @adobe/aio-cli: 6.0.0
  CLI plugins:
    @adobe/aio-cli 6.0.0 (core)
    @adobe/aio-cli-plugin-app 6.0.0 (core)
    @adobe/aio-cli-plugin-auth 2.4.0 (core)
    @adobe/aio-cli-plugin-certificate 0.2.1 (core)
    @adobe/aio-cli-plugin-cloudmanager 1.3.5 (user)
    @adobe/aio-cli-plugin-config 2.3.0 (core)
    @adobe/aio-cli-plugin-console 3.2.0 (core)
    @adobe/aio-cli-plugin-events 1.1.0 (core)
    @adobe/aio-cli-plugin-info 1.1.1 (core)
    @adobe/aio-cli-plugin-runtime 3.1.0 (core)
    @oclif/plugin-autocomplete 0.3.0 (core)
    @oclif/plugin-help 2.2.3 (core)
    @oclif/plugin-not-found 1.2.4 (core)
    @oclif/plugin-plugins 1.9.5 (core)
    @oclif/plugin-warn-if-update-available 1.7.0 (core)

Sample Code that illustrates the problem

Logs taken while reproducing problem

if a different program defined in .aio wants to be accessed the access_token in global config prevents it:
› aio cloudmanager:list-programs
› Error: [CloudManagerSDK:ERROR_LIST_PROGRAMS] Cannot retrieve programs: https://cloudmanager.adobe.io/api/programs (403 Forbidden) - Detail: Profile is not valid (Code: 403025)

Relates to #33

Description

When invoking an action that use the lateset aio-lib-ims and was deployed via aio app deloy (built with webpack) we get the following error:

    "result": {
      "error": "Initialization has failed due to: Error: Cannot find module '/package.json'\n    at webpackEmptyContext (/nodejsAction/ov9Ltpr6/index.js:126097:10)\n    at checkNodeVersion (/nodejsAction/ov9Ltpr6/index.js:52777:43)\n    at Object.<anonymous> (/nodejsAction/ov9Ltpr6/index.js:52783:1)\n    at Object.module.exports.Object.defineProperty.value (/nodejsAction/ov9Ltpr6/index.js:52793:30)\n    at __webpack_require__ (/nodejsAction/ov9Ltpr6/index.js:21:30)\n    at Object.module.exports.webpackEmptyContext.keys (/nodejsAction/ov9Ltpr6/index.js:125795:19)\n    at __webpack_require__ (/nodejsAction/ov9Ltpr6/index.js:21:30)\n    at Object.module.exports.Object.defineProperty.value (/nodejsAction/ov9Ltpr6/index.js:51875:36)\n    at __webpack_require__ (/nodejsAction/ov9Ltpr6/index.js:21:30)\n    at Object.<anonymous> (/nodejsAction/ov9Ltpr6/index.js:49883:17)"
    },

The same error appears if we unzip dist/myaction.zip and import the index.js in a node REPL

Reproduce

• aio app init -> select only actions
• npm install @adobe/aio-lib-ims
• require the lib in the action
• aio app deploy
• invoke the action => ERROR

Workaround (partial)

use aio-lib-ims 4.0.1 to access the Ims object, getToken won't work because of #33

What causes the error

In 4.0.1...4.1.0#diff-d8c50dc3673a2b383c6c1a0a0c19799fR17-R19, removing the import to const imsCliPlugin = require('@adobe/aio-lib-ims-oauth/src/ims-cli') and const imsOAuthPlugin = require('@adobe/aio-lib-ims-oauth') fixes the problem

Relates to #61

Provide a way to programmatically delete the ims.config.current config without having to use aio-lib-config.
This can be used to reset the context back to the default CLI context in a desktop environment

We should also expose this in the auth plugin

See adobe/aio-cli-plugin-app#243
and adobe/aio-lib-ims-jwt#18

Since adobe/aio-lib-ims-jwt#18 is a breaking change, we bump this to a major version as well, after changing the dep version in package.json

The API doc states that setting local=true in the context.set call will disable persistence when running in Runtime actions.

The readme doc shows an initial context.set call to set the JWT configuration and the user might falsely assume that setting local=true in that initial call will disable persistence.

The user however has no control over persistence, because tokens are always persisted during the getToken call, which internally always calls context.set with local=false. See https://github.com/adobe/aio-lib-ims/blob/master/src/token-helper.js#L155

The devDependency codecov was updated from 3.6.4 to 3.6.5.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

codecov is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The dependency @adobe/aio-lib-core-config was updated from 1.2.0 to 1.2.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@adobe/aio-lib-core-config is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

@fmeschbe Ok if I rename it to aio-lib-core-ims and change all references in the other repos?
(similar request for the other libraries with aio-cna-core in the name)

Depends on #22
See adobe/aio-lib-core-networking#14

Test files:

1. https://github.com/adobe/aio-lib-ims/blob/master/test/token-helper.test.js
2. https://github.com/adobe/aio-lib-ims/blob/master/test/token.helper.webpack.test.js

There is a lot of duplication in here, and there exists a test (getTokenWithOptions - string (jwt)) that does not exist in the other, and some minor differences. The only differences should be:

1. global.WEBPACK_ACTION_BUILD = true (for webpack tests)
2. getToken (string - cli) test should reject for webpack tests, resolve otherwise
3. getToken (string - oauth) test should reject for webpack tests, resolve otherwise

The issue is the loading of

This can be mitigated by dynamically loading the module and using jest.isolateModules (was only available in Jest 24+): https://jestjs.io/docs/jest-object#jestisolatemodulesfn

src/context.js:28:const CLI = '$cli'

depends on adobe/aio-cli-plugin-auth#43 auto-migrate

This issue is a dependency of:

• adobe/aio-lib-ims-oauth#26
• adobe/aio-cli-plugin-app#259
• adobe/aio-cli-plugin-console#148
• adobe/aio-cli-plugin-auth#45
• move in aio-cli-plugin-events too

The private key passphrase should not be stored in the config on disk, but the aio-lib-ims-jwt ims plugin requires it as a property on the context to unlock the private key. This is not secure. The passphrase is often a transient value provided as a flag via the CLI.

We need a way to:

1. use an in-memory-context config that can be modified without it being written to disk (so you can set the passphrase property, for example)
2. getToken should use this in-memory-context config

We run the e2e tests daily via the aio-e2e-tests repo. The connection to IMS sometimes fails because we can't exchange a jwt token, and we should be using aio-lib-core-networking to do a retry with fallback.

Test failures:

FAIL e2e/e2e.js
  ✓ init test (4ms)
  ✓ getAccessToken (224ms)
  ✕ exchangeJwtToken (196ms)
  ✕ getTokenData (1ms)
  ✕ getOrganizations (1ms)
    at Function.module.exports.sync (/home/runner/work/aio-e2e-tests/aio-e2e-tests/node_modules/execa/index.js:187:17)
    at runOne (/home/runner/work/aio-e2e-tests/aio-e2e-tests/src/run.js:71:9)
    at /home/runner/work/aio-e2e-tests/aio-e2e-tests/src/run.js:132:9
    at Array.forEach (<anonymous>)
    at runAll (/home/runner/work/aio-e2e-tests/aio-e2e-tests/src/run.js:126:29)
    at processTicksAndRejections (internal/process/task_queues.js:95:5) {
  command: 'npm run e2e',
  exitCode: 1,
  exitCodeName: 'EPERM',
  stdout: '\n' +
    '> @adobe/[email protected] e2e /home/runner/work/aio-e2e-tests/aio-e2e-tests/.repos/aio-lib-ims\n' +
    '> jest --config e2e/jest.config.js\n',
  stderr: undefined,
  failed: true,
  timedOut: false,
  isCanceled: false,
  killed: false,
  signal: undefined
}

getSusiUrl should NOT require scope, or redirect_url
both of these values CAN have default registered values in IMS
Currently if we pass scope:null, or callbackUrl:null to this function, it will add &scope=null to the url which will fail.

Should this be logged? If it should be logged, perhaps we should obfuscate (print out the last N chars only, just for debugging purposes)

As JWT service authentication is gonna be deprecated the new OAuth authentication should be supported in parallel. It is described in https://developer.adobe.com/developer-console/docs/guides/authentication/ServerToServerAuthentication/implementation/.

README.md:50:All configuration is stored in a single `$ims` root property.
README.md:53:Each such configuration is stored in its own named object with the `$ims` configuration.
README.md:57:Inside the `$ims` configuration object, the name of the _current context_ is stored in the `$current` property.
README.md:59:Here is an example `$ims` configuration
README.md:63:  $ims: {
README.md:226:Additional plugins must be `npm install`-ed and listed in the `$ims/$plugins` array property.
src/context.js:25:const IMS = '$ims'
test/context.test.js:31:  expect(ctx.IMS).toEqual('$ims')
test/token-helper.test.js:23:    // prefix $ims. to all the keys
test/token-helper.test.js:26:        [`$ims.${key}`]: context[key]
test/token-helper.test.js:36:    '$ims.$plugins': imsPlugin ? [imsPlugin] : null

See adobe/aio-cli-plugin-auth#43 for new format

Is your feature request related to a problem? Please describe.
IMS access token creation currently only supports JWT based, OAuth2, and CLI access tokens. Other access token types might be added in the future. So it would be beneficial to add back configurable token creation plugin support to add more types of access token creation.

Describe the solution you'd like

• Expose API in the Context class to retrieve and update additional token creation plugins
• Add support to the token generation function to consider the configured token creation plugins in the selection process

Describe alternatives you've considered
n/a

Additional context
n/a

See example adobe/aio-lib-core-config@2b41d81

1. package.json scripts
2. jsconfig.json
3. files key in package.json (if used)

(Fix JSDoc issues)

Describe the bug
Link leads to 404 - Not Found page.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'https://github.com/adobe/aio-lib-ims#running-in-an-adobe-io-runtime-action'
2. Click on 'App Builder Security Guide'
3. See error

Expected behavior
Opening he actual site with the "Security Guide" content.

Describe the bug
When following OAuth Server-to-Server configuration in the readme an error is returned: [IMSOAuthSDK:MISSING_PROPERTIES] OAuth2 not supported due to some missing properties: technical_account_email,technical_account_id,ims_org_id"

By reading the code in https://github.com/adobe/aio-lib-ims-oauth/blob/master/src/ims-oauth_server_to_server.js it is clear that the properties need to be as follows:

Describe the bug
If I have a context configuration that holds an access_token and/or refresh_token and that it gets invalidate outside of this context, then on the next getToken, as long as the token is not expired it will be returned although it's invalid.

This applies for both action and cli config

Reproduce

const { Ims, getToken, invalidateToken, context } = require('.')

const config = {
    client_id: "<jwt-clientid>",
    client_secret: "XXX",
    techacct: "<guid>@techacct.adobe.com",
    meta_scopes: [
      "ent_dataservices_sdk"
    ],
    ims_org_id: "<org-guid>@AdobeOrg",
    private_key: "XXX"
}

await context.set('my-ctx', config)
const token = await getToken('my-ctx')

// await invalidateToken('my-ctx') => would delete the token in the config

// but if the token is invalidate elsewhere the token would still be in the config
// example
const ims = new Ims('prod')
await ims.invalidateToken(token, config.clientId, config.clientSecret)

const token2 = await getToken('my-ctx') // would return the same cached token which is invalid
// furthermore now a call to invalidateToken will throw an error as the token is not valid

Possible solution
in every getTokenIfValid call in token-helper.js validate the token against IMS, however this will trigger many more requests and reduces the advantage of caching the token

The devDependency stdout-stderr was updated from 0.1.9 to 0.1.10.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

stdout-stderr is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Especially for Runtime action contexts where caching goes to state lib

Right now, if your context does not support the properties needed for the OAuth, or JWT IMS plugins, it will show this error:
Error: cannot generate token because no plugin supports configuration

This error is not very descriptive. There is more info when prefixing this environment variable DEBUG=@adobe/aio-lib-ims:token-helper before your command.

The IMS plugins do check for missing keys, and we can expose the missing keys in aio-lib-ims for reporting: https://github.com/adobe/aio-lib-ims-jwt/blob/f5028aa800c41f53aac663c4ccdcbae4c672263c/src/ims-jwt.js#L39

The issue is, if it is missing properties for a plugin, that's ok, it can match for another plugin. If it does not match all plugins, we need to print out the error message for all the plugins (missing key(s)), so the user can see and filter for themselves.

Expected

When an ims context does not match any IMS plugin, this error is shown:

context properties: ['...']
@adobe/aio-lib-ims-jwt: missing keys(s) ['private_key']
@adobe/aio-lib-ims-oauth: missing keys(s) ['scope', 'redirect_uri' ]

Actual

When an ims context does not match any IMS plugin, this error is shown:
Error: cannot generate token because no plugin supports configuration

Describe the bug
App Builder action is making a call to get an IMS token via OAuth Server-to-Server

When invoking an app builder action which has been deployed using aio app run making a call to get an IMS token via OAuth Server-to-Server the script returns the below error:
{ "error": "An error has occurred: IMSLibError: [IMSSDK:CANNOT_GENERATE_TOKEN] Cannot generate token because no plugin supports configuration:\n[plugin:jwt]: [IMSJWTSDK:MISSING_PROPERTIES] JWT not supported due to some missing properties: client_secret,meta_scopes,private_key" }

When the same action is run locally via node ./action/action-name/index.js the action works as expected and a token is returned.

Code being used:

const { context, getToken, getTokenData } = require('@adobe/aio-lib-ims');

async function main(params) {
  const config = {
    client_id: '_redacted_',
    client_secrets: ['_redacted_'],
    ims_org_id: '_redacted_',
    scopes: ['AdobeID', 'openid', 'read_organizations', 'additional_info.projectedProductContext', 'additional_info.roles', 'adobeio_api', 'read_client_secret', 'manage_client_secrets', 'event_receiver_api'],
    technical_account_email: '_redacted_',
    technical_account_id: '_redacted_',
  };
  await context.set('imsToken', config);

  const token = await getToken('imsToken');
  const tokenDecoded = getTokenData(token);
  console.log(token, tokenDecoded);
  return { token, tokenDecoded };
}
exports.main = main;

To Reproduce

1. Create action which uses @adobe/aio-lib-ims to get a token using OAuth Server-to-Server
2. Deploy action via aio app run
3. Invoke aciton via aio rt action invoke *action name* --result
4. Observe error above

Expected behavior
A token is returned

Describe the bug

On https://github.com/adobe/aio-lib-ims/blob/master/api.md#module_@adobe/aio-lib-ims.getToken, there's a sentence:

See Forced imsLogin for more information on this flag.

Where "Forced imsLogin" is a link to https://github.com/adobe/aio-lib-ims/blob/master/README.md#forced-imslogin, but that anchor is not present in the README.

To Reproduce

Go to the API Documentation. Click the link

Expected behavior

Unclear to me what is intended to be documented. I suppose some definition of what "forced" means.

The devDependency eslint-plugin-jest was updated from 23.6.0 to 23.7.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint-plugin-jest is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Currently, all IMS plugins that are used are hardcoded, and there is no current use case to dynamically load and use an ims plugin.

To specify an ims plugin, you would add the plugin package name in the ims.config.plugins array. Even if you added the plugin in the config, during runtime node may have trouble resolving where the plugin is, and you will have to add where it is by appending to the NODE_PATH environment variable.

Also, the dynamic nature of resolving ims plugins is causing problems with webpack and Adobe I/O Runtime functions. See #33.

Describe the bug
The new config changes lack documentation in the README - short blurb maybe on how it will work in cli versus an action.
The new API changes need to be reflected in the README as well.