botbuildercommunity / botbuilder-community-js Goto Github PK

botbuilder-config

For example, instead of having to get the subscription keys, access keys, etc. for QnA Maker by grabbing it off of the object, you could do a c.QnAMaker().getOptions() and it would return the exact options structure needed for the middleware.

Moved from previous repository.

Right now tests are simply an example bot that you can run manually. We should incorporate Mocha as the unit test framework, and then use the TestAdapter in the Bot Framework to help run the tests. Examples for the Node.JS usage of the TestAdapter can be found in the Bot Framework source code, as well as some of the libraries tests.

Broken out of #60.

botbuilder-config

In the event the PR for the botbuilder-tools is delayed, or not accepted, need to be able to dynamically construct the endpoint URL.

The botbuilder-tools repo has an issue 330 that seems to suggest Microsoft wants to use authoringRegion instead of an endpoint, and that the endpoint may be dynamically constructed. Will need to modify the code, so that there is a getter/setter for endpoint that constructs the URL itself.

Moved from previous repository.

Add a changelog to every package, which shows updates and breaking changes according to Keep a changelog and semver.

Could be used as source for releases on Github etc.

Previously I have created botbuilder-facebookextension, however this one only supports v3 and hasn't been updated in 2 years.

A recent query on SO reminded me of the package and the need.

Currently, the libraries folder has each package, and each package is prefixed with "botbuilder-". Should we change that prefix to be "botbuildercommunity-"? Should we remove the prefix entirely?

For reference, the NPM packages are scoped to the @botbuildercommunity organizations, so the botbuilder-adapters folder aligns with the @botbuildercommunity/adapters NPM package.

This is more an internal repository structure question/change than anything.

Opinions?

Currently breaking the CI/CD build. The issue is with a dependency of the API SDK. An upgrade to 5.x.x for the IBM Watson SDK will fix this, but it's a major version release which breaks our packages tests. Will need to upgrade the SDK and then update our package.

The botbuilder-azuretablestorage folder should be renamed botbuilder-storage, and the NPM package should be renamed @botbuildercommunity/storage to put it in the org scope like the other packages. Will need to deprecate the previous package in NPM. This will allow us to build out additional storage middleware and options in a single package.

botbuilder-config

Looks like Microsoft might already be creating their version of a configuration consumer/decrypter, and seem to be making changes to the algorithm. This could mean breaking crypto changes that will have to be folded into this.

Moved from previous repository.

Right now the Twitter adapter is respond-first. If the user sends a tweet, it’ll respond with a tweet. If a direct message, it’ll respond with a direct message. Need to allow the adapter (and chatbot) to kick off a message of the user’s choice.

For classes that accept multiple arguments in the constructor, what is the standard practice? Should it always been a settings/configuration object, or are there times when it makes sense to pass in multiple arguments accompanied by an options parameter?

Based on:
#70 (comment)

Currently, we have example usage in example folders under each library package. We should probably pull these out and put them in a samples folder in the root to mirror what the dotnet team is doing.

This needs to be refactored. It grew a little kludgy while testing and fixing.

As per @iMicknl's comment:
#70 (comment)

Will require a new NPM with token.

Also, configuration might need to change once all are in a single repository.

Broken out of #60 and currently WIP by @iMicknl with #95 using the Bot Builder Community's .NET version as a baseline.

Broken out of #60.

Pre 1.0.0 release

Post 1.0.0 release

• Close #83
• Deprecate @botbuildercommunity/adapters and refer to @botbuildercommunity/adapter-console.
• Review all CHANGELOG.md files and add publication date.

Suggested by @iMicknl to clean up the code, and make it more uniform. Would align us with the Bot Framework team's usage.

As per this conversation with @iMicknl:
#70 (comment)

We should consider simplifying the .gitignore and the .npmignore and keep them in the root with overrides in the subfolders.

As discussed with @iMicknl, and noted in #63, we should take packages like the adapters and storage and break them out more, but leave the top level one for "install all" capabilities.

I like how Text Recognizers are handled.

For storage, it could be:
npm install @botbuildercommunity/storage for the suite and...
npm install @botbuildercommunity/storage-ats to get just the Azure Table Storage.

For adapters, it could be:
npm install @botbuildercommunity/adapters for the suite and...
npm install @botbuildercommunity/adapters-console to get just the console adapter.

Open to thoughts/suggestions.

With some prompts, it makes sense to limit the result to a single value, but with others, it would be more valuable to return an array of values. We should identify which ones this applies to, and make the appropriate adjustments.

I left the .vscode folders in the repos because it made it easier for me. Probably isn't the best idea. As per this comment from @iMicknl:
#70 (comment)

...we should probably ignore them.

The current version of the adapters package is published to npm as Typescript only. This should be compiled to Javascript and republished.

As referenced in #70 and originally discussed in #64, we need to break apart "collective" packages to give users individual choice, but also have an overall "suite" install still in place. While looking into this for my recent Watson integration, I realized that we ended middleware packages with "middleware", and likely put that in the wrong place.

As per my PR, we probably want to do something like this:

• botbuilder-middleware
• botbuilder-middleware-engines
• botbuilder-middleware-text-analytics
• botbuilder-middleware-watson-nlu

...which would mean changing something like "botbuilder-text-analytics-middleware" to "botbuilder-middleware-text-analytics". This is better in my opinion because of tab completion and search.

If implemented, however, it would require changes to the folder structure and NPM package (deprecating old ones) for the above, as well as the spell check and recognizers middleware to bring everything into alignment.

Right now--for publishing--we're only ignoring the node_modules folder. We should probably ignore other things like example and test folders. Things that a production package doesn't need.

For the botbuilder-dialogs-prompts, running the tests throws the following error per dialog prompt:

Error: DialogSet.add(): Invalid dialog being added.
      at DialogSet.add (test\node_modules\botbuilder-dialogs\lib\dialogSet.js:190:19)
      at Context.it (test\index.test.js:33:17)

The code for these dialog prompts parallels the dialog prompts in the Microsoft repo. Not sure what the failure is coming from. Needs further investigation.

The community dialog prompts from the dotnet repo are the ideal candidate(s) for a first attempt at porting over some dotnet items to NodeJS.

Does it make sense to list the supported Node version? I had an older version of Node and came across this issue:
#63 (comment)

...when reviewing @iMicknl's Twilio WhatsApp adapter. My version could have just been too old though.

What is the standard practice?

Once the package was finished, only a single API call ended up using the “twitter” package. The rest had to be custom. Need to convert the final one to request-promise and remove the package.

Would be great to have a Node version of the .net sentiment middleware (https://github.com/BotBuilderCommunity/botbuilder-community-dotnet/tree/master/libraries/Bot.Builder.Community.Middleware.SentimentAnalysis).

Some channels (like experimental WhatsApp) just support images and don’t support Adaptive Cards. It would be great if there was a middleware, which could be used to transform adaptive cards to images for selected channels.

As far as I know, this is something that is be done by default in the Bot Service. However, this isn’t available for the custom adapters.

Currently, the latest Adaptive Cards package doesn’t offer an AdaptiveCardRenderer to Image API for NodeJS (microsoft/AdaptiveCards#1012), only for C# (microsoft/AdaptiveCards#930). So it has to be a custom renderer in NodeJS.

I requested the creators of this mongodb library move it to the BotBuilderCommunity repository. However, they objected that the community repository does not have everything separated into different modules: botbuilder-contrib/botbuilder-storage-mongodb#10

Add the botbuilder-azuretablestorage repository code and archive the previous version.

The botbuilder-config package was created because at the time, the Bot Framework had no way of consuming the bot files and using them in chatbots. Microsoft has since created a botframework-config package to do this. The botbuilder-config has enough variance (and future functionality), that I want to keep it active, but we should extend the botframework-config package to avoid reinventing the wheel.

This could also be implemented for the NPM packages in botbuilder-community-tools. There is a module called badges that looks like a lot of people utilize. Open to this or another solution to align the design of the JavaScript/TypeScript projects with the NuGet badges in the dotnet repo.

Would be nice to have support for Alexa, Google Assistant and Twitter DM for Javascript based bots.

Tracking issue for the migration:

• Alexa Adapter
• Google Adapter
• Twitter Adapter

I will try to make some time for this in the coming weeks. @szul are you aware if someone already started working on this?

Hi all,

I'm trying to use the Google Bot Adapter and having some issues, first had to adapt the path to /api/actionrequest which is different from the documentation.

After that we had a bug on the following line inside GoogleAdapter.cs (line 116) where Arguments was null and we did not have the ? operator)

        if(actionPayload.Inputs.FirstOrDefault()?.Arguments?.FirstOrDefault()?.Name == "OPTION")

After that when trying to run the sample bot testing via the Actions On Google simulator, I get the following error:

API Version 2: Failed to parse JSON response string with 'INVALID_ARGUMENT' error: "payload: Cannot find field.".

Am I doing something wrong? Should this be working?

Thanks

No package updates from Google yet to resolve this. Currently breaking the CI/CD build. The issue is with a dependency of the API SDK.

The code ported from the Microsoft repo has this issue attached:
microsoft/botbuilder-js#277

...which seems to be related to this issue as well (for blob storage):
microsoft/botbuilder-js#314

A recent PR (microsoft/botbuilder-js#369) fixes it for the blob storage, and we might be able to piggyback off of it for a fix here, but the PR is on hold right now.

As per @iMicknl's comment on PR #38: The individual package calls to tsc in their local node_modules folders was replaced with just tsc. This is because a configuration of:

"postinstall": "./node_modules/.bin/tsc -p ."

or

"postinstall": "./node_modules/.bin/tsc"

...throws an error when lerna bootstrap is run of:

'.' is not recognized as an internal or external command

This seems to be an issue with pathing to the TypeScript executable when running Lerna. I could possibly resolve this by putting TypeScript at the root level along with Lerna, and using that for building. The problem is that the postinstall script runs after the NPM module is installed by the user, so that's why local TypeScript installs were added.

Is this necessary?

When the NPM module is published, I believe it publishes from the local folder, so it should include the built JavaScript files, even though they are not in GitHub. If this is correct, we could eliminate the postinstall script in favor of a build script.

Open to suggestions.

Add the botbuilder-config repository code and archive the previous version.

After the upgrade, the following errors are encountered when running npm run test:

C:\Users\micha\x\botbuilder-community-js\libraries\botbuilder-dialog-prompts\node_modules\botbuilder-dialogs\lib\prompts\oauthPrompt.js:235
            catch {
                  ^

SyntaxError: Unexpected token {
    at createScript (vm.js:80:10)
    at Object.runInThisContext (vm.js:139:10)
    at Module._compile (module.js:607:28)
    at Object.Module._extensions..js (module.js:654:10)
    at Module.load (module.js:556:32)
    at tryModuleLoad (module.js:499:12)
    at Function.Module._load (module.js:491:3)
    at Module.require (module.js:587:17)

This seems to be pointing to a file in the botbuilder-dialog package in the Bot Framework.

Right now they just link to the SVG of the badge itself.