Open ericrrichards opened 4 months ago
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.
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.
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.
@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.
+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.
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.
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:
With this error:
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?
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