-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix unpslash author meta, sanitize metadata to strings and improve companion tests #3478
Conversation
add `npm run test:companion:watch` move env variables into code to make testing easier this allows for watching (source is causing problems with npm scripts) also now we can run `corepack yarn test:companion -t 'single test'`
make sure we don't run companion tests on npm run test:unit (as they don't work in a browser/jsdom environment)
previously incorrect options gives an Uploader object in an incorrect state
Ok the end-to-end-test fails, good! means it's working. Now need to fix this in the unsplash plugin |
causing error #3477
related: form-data/form-data#137 |
# Conflicts: # packages/@uppy/provider-views/src/View.js
like the official FormData spec does
async tryUploadStream (stream) { | ||
try { | ||
const ret = await this.uploadStream(stream) | ||
if (!ret) return |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to pentition for us to start using nullish comparisons instead of falsy ones. Using falsy can be a footgun (because 0
and the empty string are falsy), and imho it's more readable and is more self-explanatory.
if (!ret) return | |
if (ret == null) return |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that nullish comparison is better when the function is expected to sometimes return a value where we consider 0 or '' to be valid values. In this case,if (ret == null) return
would not return if ret
by mistake is 0 or '', and it would continue on to the next line and crash, so I feel that !ret
is "safer", as it will match more strictly. (it will return on more invalid values). do I make any sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree it's "safer", I would argue the opposite: if the function returns 0
or an empty string it's almost certainly an error that we want to fix so I think a crash is more helpful than silently swallowing the type mismatch. Also, it wouldn't help if the function returns e.g. 1
.
Anyway, if we really cared this kind of safety, we would write TypeScript (or make JSDoc mandatory) so I don't feel strongly about it, use the syntax that makes the more sense to you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually when I think about it if we use if (ret == null) return
, and ret is 0, then it would:
const { url, extraData } = 0
so it wouldn't crash, but it would emitSuccess(undefined, undefined)
Honestly I'm not sure what is best in this case, I just felt that !ret
would be less likely to lead to strange behavior if ret was not an object, which is what we want in the success-case. Is there any way we can enforce x != null
instead of !ret
with eslint?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose we could turn on an option to force to write == true
for all conditions, but that would make checking for actual boolean value needlessly verbose, so I would be hesitant to turn on such option...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah ok. Then I think unless we can enforce it with jsdoc or TS like you say, I'm probably going to have a hard time adjusting to using that 😄 but I can try!
bin/companion.js
Outdated
@@ -0,0 +1,2 @@ | |||
require('dotenv').config({ path: '.env.local' }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes me think we should probably go back to using .env
instead of .env.local
. I thought .env.local
was standard and would be picked up by dotenv by default, but it looks like it's not the case...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I thought we initially had a .env
file too in addition to .env.local
, although I cannot find it anywhere. Then I thought .env.local was local (dev) overrides for .env
. That is how I'm used to it working in create-react-app.
But unless we want to commit a .env
with default values, then I agree we can instead just use .env
, because it doesn't seem like dotenv supports .env.local
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, my original idea was to have a .env
file that would contain the default values, and have a .env.local
file that would override it. I gave up on that and went back on having only one file because:
- dotenv docs explicitly recommend against that: https://github.com/motdotla/dotenv#should-i-have-multiple-env-files.
- It made overriding config for the e2e CI tricky.
(It looks like Merlijn went through a similar train of thought as he also settled on using only .env
on his own)
Let me open a PR to address that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah. Yes dotenv
also recommends against commiting .env files or env variables. Same with the 12 factor app. But then dotenv is more geared towards backend node.js apps where .env files contain actual secrets. create-react-app on the other hand does recommend commiting .env files. But then on the flipside because frontend apps will usually expose all env variables in the bundled code anyways, it doesn't make sense to try to keep them secret. Our .env is a mix between backend and frontend, so then who knows what's right 🤷♂️
But I think keeping .env out of git is the only safe common denominator
Looks like the merge commit did some weird stuff, can you do: git rm bin/companion.js
git checkout main -- README.md |
Oh yea I noticed that too. I think it's due to the fact that we have a pre-commit hook that mutates files right before commiting: Line 9 in c2692e4
I think we should remove all the --fix and the commands that will mutate, what do you think? |
Yea it keep modifying readme.md so even after running |
Nah let's keep those |
I removed all --fix from eslint and |
I absolutely agree that we should keep precommit hooks to catch lint errors before commiting, but I don't think they should modify code silently before commiting. It can lead to strange things like this when merging. |
Can you |
I guess it could be discussed, but it has little to do with unsplash and should go in its own PR. |
true, I can create a separate issue about it. but I'm afraid if I revert it now, then readme will be modified again |
ok I think I managed to push it without running the commit hooks first! |
I have a fix PR for the README formatting: #3499 |
| Package | Version | Package | Version | | --------------- | ------- | --------------- | ------- | | @uppy/companion | 3.3.0 | uppy | 2.6.0 | | @uppy/robodog | 2.3.2 | | | - meta: warn about not merging PR manually (Artur Paikin / #3492) - @uppy/companion: fix unpslash author meta, sanitize metadata to strings and improve companion tests (Mikael Finstad / #3478) - meta: ensure README is correctly formatted when doing releases (Antoine du Hamel / #3499) - meta: fix CDN bundle (Antoine du Hamel / #3494) - meta: fix missing EOL and end of e2e test templates (Antoine du Hamel / #3484) - meta: use a single `.env` file for config (Antoine du Hamel / #3498)
…mpanion tests (transloadit#3478) * fix broken npm run test * improve jest / companion add `npm run test:companion:watch` move env variables into code to make testing easier this allows for watching (source is causing problems with npm scripts) also now we can run `corepack yarn test:companion -t 'single test'` * fix root project jest make sure we don't run companion tests on npm run test:unit (as they don't work in a browser/jsdom environment) * improve validation logic previously incorrect options gives an Uploader object in an incorrect state * rewrite uploader to make it more testable * add test for xhr * check that metadata values are strings * fix nested meta causing error transloadit#3477 * convert meta to strings instead like the official FormData spec does * fix broken companion dev transloadit#3473 * fix botched merge * fix botched merge and remove --fix * fix botchedf merge * quick fix * . * remove eslint fix
| Package | Version | Package | Version | | --------------- | ------- | --------------- | ------- | | @uppy/companion | 3.3.0 | uppy | 2.6.0 | | @uppy/robodog | 2.3.2 | | | - meta: warn about not merging PR manually (Artur Paikin / transloadit#3492) - @uppy/companion: fix unpslash author meta, sanitize metadata to strings and improve companion tests (Mikael Finstad / transloadit#3478) - meta: ensure README is correctly formatted when doing releases (Antoine du Hamel / transloadit#3499) - meta: fix CDN bundle (Antoine du Hamel / transloadit#3494) - meta: fix missing EOL and end of e2e test templates (Antoine du Hamel / transloadit#3484) - meta: use a single `.env` file for config (Antoine du Hamel / transloadit#3498)
While working on #3477 I needed to make it easier to test the Uploader to create a regression test for testing the metadata. Once that issue is resolved and this is merged, we will be able to more easily write a test that confirms the metadata behavior for nested objects
all changes:
npm run test:companion:watch
corepack yarn test:companion -t 'single test'
npm run test
Update:** have now also added validation of metadata to this PR (only allow string metadata values)Update2: have also flattened the nested author from unsplash