Closed emilong closed 3 years ago
Any way I can test this? I tried:
Cypress adds a .then
function to the result of e.g. base64StringToBlob
val.then = function () {
$errUtil.throwErrByPath('breaking_change.blob_util2', {
args: {
functionName: key,
},
})
}
Perhaps wrapping it around Cypress.Promise.resolve(...)
still invokes the .then
method that was added by Cypress?
According to the bluebird docs:
http://bluebirdjs.com/docs/api/promise.resolve.html If value is a thenable (Promise-like object, like those returned by jQuery's $.ajax), returns a trusted Promise that assimilates the state of the thenable.
Maybe @jennifer-shehane can shed some light on this? What else would have to be done to have a working blob-util again?
We added the .then
to try and add a better error message when using the old API, but now it's clear that wasn't a great idea since it gets confused for a 'thenable'.
You should be able to work around it by using Promise.try
instead of Promise.resolve
:
// before:
Cypress.Promise.resolve(Cypress.Blob.base64StringToBlob(fileContent, mimeType))
// after:
Cypress.Promise.try(() => Cypress.Blob.base64StringToBlob(fileContent, mimeType)))
Cypress.Promise.try(() => Cypress.Blob.base64StringToBlob(fileContent, mimeType)))
I tried with this code instead, but I get the very same result...
base64StringToBlob() no longer returns a Promise. Update the use of base64StringToBlob() to expect a returned Blob.
Thanks, @chrisbreiding! I missed that detail... still a bit early in the morning :sweat_smile: :coffee:
Cypress.Promise.try
does not mean "meh, I don't care if it works" though.
It's just a fancy way of handling the non-async part of the potential errors.
http://bluebirdjs.com/docs/api/promise.try.html Start the chain of promises with Promise.try. Any synchronous exceptions will be turned into rejections on the returned promise.
That's my bad. I suggested it before trying it out. I had hoped it wouldn't trigger using .then
on the return value like Promise.resolve
, but it looks like it does.
Might have to resort to an ugly hack to fix this. Something like the following:
const removeThen = (value) => {
if (value) value.then = undefined
return value
}
Cypress.Promise.resolve(removeThen(Cypress.Blob.base64StringToBlob(fileContent, mimeType)))
I'm thinking we'll want to condition that on the Cypress version too? To be compatible with < 5.0.0. I'll draft it up.
Sorry for the hassle with this one. We'll improve this for the next release, but unfortunately the hack will have to remain for users on 5.0.0.
Ok, I actually did due diligence this time and confirmed https://github.com/abramenal/cypress-file-upload/pull/215/commits/efa9358efb41bb3ccadfc0632fe396d082d388b1 works on my tests locally for 4.12.1 and 5.0.0. :crossed_fingers:
Yeah, I can confirm that this fix work perfectly fine now :)
Is there an estimate for when this might be merged for the plugin? I'm trying to use the PR branch but I'm running into some issues (webpack can't resolve the module).
MaintainerNotAvailableException?
Hope this gets merged soon this works perfectly!
Can anyone help me figure out how to use the https://github.com/binti-family/cypress-file-upload/tree/cypress-v5-compat branch in my build?
What I did:
cypress-file-upload
from node_modules directory.yarn.lock
.devDependencies
in package.json
: "cypress-file-upload": "binti-family/cypress-file-upload#cypress-v5-compat",
yarn install
cypress/support/commands.js
: import 'cypress-file-upload'
When I run my test, I get this error:
rror: Webpack Compilation Error
./cypress/support/commands.js
Module not found: Error: Can't resolve 'cypress-file-upload' in '/[myroot]/cypress/support'
resolve 'cypress-file-upload' in '[myroot]/cypress/support'
Parsed request is a module
using description file: [myroot]/package.json (relative path: ./cypress/support)
Field 'browser' doesn't contain a valid alias configuration
Looked for and couldn't find the file at the following paths:
When I inspect the import
command in my IDE, I see it's linking to node_modules/cypress-file-upload/types/index.d.ts
.
I'm using yarn workspaces, so my node_modules
directory is a higher up than my package.json where I'm requiring stuff.
=== SOLVED by dragonfire1119!
cd /node_modules/cypress-file-input
yarn
yarn build
Can anyone help me figure out how to use the https://github.com/binti-family/cypress-file-upload/tree/cypress-v5-compat branch in my build?
What I did:
Delete
cypress-file-upload
from node_modules directory.Delete
yarn.lock
.Add to
devDependencies
inpackage.json
: `"cypress-file-upload": "binti-family/cypress-file-upload#cypress-v5-compat",`
yarn install
Add to
cypress/support/commands.js
:import 'cypress-file-upload'
When I run my test, I get this error:
rror: Webpack Compilation Error ./cypress/support/commands.js Module not found: Error: Can't resolve 'cypress-file-upload' in '/[myroot]/cypress/support' resolve 'cypress-file-upload' in '[myroot]/cypress/support' Parsed request is a module using description file: [myroot]/package.json (relative path: ./cypress/support) Field 'browser' doesn't contain a valid alias configuration Looked for and couldn't find the file at the following paths:
I'm using yarn workspaces, so my
node_modules
directory is a higher up than my package.json where I'm requiring stuff.
You have to go into the directory and yarn; yarn build. Yarn is not building the dist inside node_modules/cypress-file-upload.
Thanks, @dragonfire1119 ! That did the trick.
Thanks, @dragonfire1119 ! That did the trick.
You're welcome! Glad I could help! :)
@abramenal any chance you have time to check this out and either provide feedback or get a release going? really appreciate your work on this package and just hoping to unblock some folks :blush:
Shall we get this PR sooner to the release build? Blocking my test execution and refraining me from upgrade Cypress@5.0.0
Hey all! After speaking with @abramenal, it seems the best way forward is for another person to become a maintainer on this project. Looking forward to working with you all!
This is my first time being an OSS maintainer, so please be gentle.
Ok! Updated to use semver for comparison and I tried it locally on Cypress 4 and 5. Would appreciate anyone else double checking though!
@abramenal Before this gets merged, I asked the author to try a different way that introduces no new dependencies and might also be safer. Hopefully we can wait 1 more day for that.
I had a chance to update to use @josephzidell's approach and check it on Cypress 4 and 5 again.
LGTM
@all-contributors add @emilong for code
@josephzidell
I've put up a pull request to add @emilong! :tada:
Will you also make a new release?
We're working on it 🍻
@all-contributors add @josephzidell for maintenance
@abramenal
I've put up a pull request to add @josephzidell! :tada:
Thanks everyone for working on this, v4.1.0
is out 🎉🎉🎉
Unfortunately, Cypress 5 is still showing this error:
binaryStringToBlob() no longer returns a Promise. Update the use of binaryStringToBlob() to expect a returned Blob
Thank you !!! I can confirmed that it worked !! 👍
It worked for me too !! Thanks a lot
I just pulled the latest code, I can confirm the file upload is working on the latest cypress version, thank you so much guys!
Unfortunately, Cypress 5 is still showing this error:
binaryStringToBlob() no longer returns a Promise. Update the use of binaryStringToBlob() to expect a returned Blob
Having the same error here
I'm also still getting the error that @josephzidell and @JohnnyChiang mentioned. Going to downgrade again until this is stable.
@Ksan8 @josephzidell @JohnnyChiang can you say more about your set up? E.g. I'm using cypress to drive chrome only and I didn't have any other plugins/extensions that hit this issue. Those are the first two things that come to mind as being possibilities?
@Ksan8 @josephzidell @JohnnyChiang take a look at #222 and #225 to see if that is your use case. Also, 4.1.1 has been released with a fix.
Wraps return value of
Cypress.Blob.base64StringToBlob()
in aCypress.Promise.resolve
, which will allow us to treat it as a Promise no matter what. If it's already a Promise, as it was in Cypress <=4, this will be also be compatible.Fixes #214