Cannot import downscaleImageToDataURLUsingBrowser with 4.17.0

[ericrrichards]

Is it an issue related to Adaptive Cards?

No

Is this an accessibility issue?

No

What version of Web Chat are you using?

Latest production

Which distribution are you using Web Chat from?

NPM

Which hosting environment does this issue primarily affect?

Web apps

Which browsers and platforms do the issue happened?

Others or unrelated

Which area does this issue affect?

Development experience

Which theme pack does this issue affect?

I did not test it on other theme packs

What is the public URL for the website?

No response

Please describe the bug

Probably we're not supposed to be doing this, but it worked with versions <=4.16.0

We are using the downscaleImageToDataURLUsingBrowser function from botframework-webchat-component/src/Utils/downscaleImageToDataURL to generate thumbnail images for file attachments that are dropped on our webchat component via screengrab tool => copied to clipboard => pasted.

It looks as though the 4.17.0 release went live yesterday night or this morning on npm, and our builds started breaking on the line where we are doing:

import downscaleImageToDataURLUsingBrowser from "botframework-webchat-component/src/Utils/downscaleImageToDataURL";

With this error:

Module not found : error : Package path ./src/Utils/downscaleImageToDataURL is not exported from package 
{path-to-project}\node_modules\botframework-webchat-component (see exports field in 
{path-to-project}\node_modules\botframework-webchat-component\package.json) 

The only real difference I can see is that the index.js file changed to be index.ts

https://github.com/microsoft/BotFramework-WebChat/blame/f03d1f05ea6bb87dda6bea6ab42f58b1b96d9dfa/packages/component/src/Utils/downscaleImageToDataURL/index.ts#L6

This was probably not supposed to ever work, but it did through the crapulence of JavaScript and now it doesn't.

Do you see any errors in console log?

No response

How to reproduce the issue?

import downscaleImageToDataURLUsingBrowser from "botframework-webchat-component/src/Utils/downscaleImageToDataURL";

What do you expect?

Not to spend my whole day tracking down an undocumented build error.

What actually happened?

I had to explicitly set the version of botframework-webchat : 4.16.0 in my package.json

Do you have any screenshots or recordings to repro the issue?

No response

Adaptive Card JSON

No response

Additional context

No response

[OEvgeny]

The downscaleImageToDataURLUsingBrowser function was never meant to be directly used or to be a part of public WebChat API.

In the latest release, we added exports field to our package.json as we now support both ESM and CJS, and have to provide a way for runtimes and bundlers to distinguish between them. As a side-effect it protects our internal APIs from being directly imported.

Depending on the use-case you may be able to use useMakeThumbnail instead, which is publically available react hook.

If you have a use-case in mind which requires direct usage of the downscaleImageToDataURLUsingBrowser, let's discuss in this issue. We're happy to take this as an opportunity to improve our public APIs.

[ericrrichards]

Understandable, it's just frustrating because it was a breaking change for us and I wasted most of a day figuring out what the problem even was.

• NPM pakage.json dependency syntax is horrible by default, and "^4.14.0" will happily resolve to 4.17.0 instead of the real desired package version.
• There is very little good documentation on what the public API surface of the botframework-webchat API is. Somebody on my team found this usage suggested at some point - we've been using this for a number of years and probably make up a healthy of chunk of the weekly downloads on the NPM stats via our Azure Devops build agents.

[OEvgeny]

While I understand the frustration, I have to point out that we do not support or promote undocumented APIs usage. The issue is the only issue mentioning this particular function.

Keeping our documentation clean and concise, and all publicly available APIs mentioned is one of our goals. If you don't see a function mentioned in our docs, this most likely means it is not a part of our public API. Feel free to open an issue if you see any particular problems with our documentation.

To address some use-cases we have a plan to expose a small set of internal APIs under botframework-*/internal, but we haven't discussed downscaleImageToDataURL utility function in particular. That said if you have use-cases, feel free to share so we could decide with your particular case in mind. The internal APIs available this way are still not recommended for usage though.

[compulim]

@ericrrichards I understood your frustration on ^4.14.0 resolves to 4.17.0.

To be honest, I would love to follow semantic versioning precisely and update the major version when we introduce new features or breaking changes. But unfortunately, I don't have control over the first digit of the version number.

I will document it in README.md. In the meanwhile, could you use ~4.14.0? This will move you up the 4.14.* but not 4.*.

Appreciated.

p.s. I will give feedback to our orgs about semantic versioning.

[SamuelTassell]

+1 for the internal functions being clearly separated, I'm assuming many head to the source instead of the hooks, depending on use case, potentially a case for an additional test. We were importing an internal function directly, thus including the exports in the package.json was a breaking change for us and a bit of a (admittedly self inflicted) time sink. Not using the available hook wouldn't haven't created this issue but as this is old code that has been in place as this project has matured, refactoring was overlooked for speed. Not a criticism, just my 2 cents.

[ericrrichards]

I appreciate the responses - I would agree that this has been a mostly self-inflicted bit of pain because we were doing something we were never supposed to be doing. We'll update eventually to use the hook or write our own code for that, but for now we're sticking at 4.16.0 until we have space to deal with it properly.

I've got a good deal of frustration at the moment with anything Teams-related, because there are a lot of moving parts right now.
I assume because they are shifting to the new Teams client while it isn't really ready yet. Every week for the last couple months I've been dealing with something in the Bot Framework back-end services that was stable for 4-5 years that has had some new breaking change deployed. Today, it's that my bot can no longer download images that a user has copy/pasted into the desktop Teams client using the smba.trafficmanager.net URL that is provided in the file attachment object I receive in the message activity. Something that has worked for five years is broken and I've got to scramble to build a patch and get the ball rolling to deploy that to a bunch of on-premise F500 customers.