Skip to content
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

Merged
merged 18 commits into from
Feb 17, 2022

Conversation

mifi
Copy link
Contributor

@mifi mifi commented Feb 9, 2022

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:

  • add test for xhr
  • improve validation logic - previously incorrect options gives an Uploader object in an incorrect state
  • 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)
  • 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 broken 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
  • Update3: stringify all metadata for form-data to prevent crash and add integration tests for it

mifi added 7 commits February 9, 2022 21:54
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
@mifi mifi changed the title Improve companion tests Check that metadata values are strings and improve companion tests Feb 10, 2022
@mifi
Copy link
Contributor Author

mifi commented Feb 10, 2022

Ok the end-to-end-test fails, good! means it's working. Now need to fix this in the unsplash plugin

causing error #3477
@mifi mifi changed the title Check that metadata values are strings and improve companion tests fix unpslash author meta, validate metadata and improve companion tests Feb 10, 2022
@mifi mifi requested a review from aduh95 February 12, 2022 16:00
@arturi
Copy link
Contributor

arturi commented Feb 14, 2022

related: form-data/form-data#137

mifi added 2 commits February 16, 2022 21:59
# Conflicts:
#	packages/@uppy/provider-views/src/View.js
like the official FormData spec does
@mifi mifi requested a review from arturi February 16, 2022 16:17
@mifi mifi changed the title fix unpslash author meta, validate metadata and improve companion tests fix unpslash author meta, sanitize metadata to strings and improve companion tests Feb 17, 2022
async tryUploadStream (stream) {
try {
const ret = await this.uploadStream(stream)
if (!ret) return
Copy link
Contributor

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.

Suggested change
if (!ret) return
if (ret == null) return

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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...

Copy link
Contributor Author

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' })
Copy link
Contributor

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...

Copy link
Contributor Author

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

Copy link
Contributor

@aduh95 aduh95 Feb 17, 2022

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:

  1. dotenv docs explicitly recommend against that: https://github.com/motdotla/dotenv#should-i-have-multiple-env-files.
  2. 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.

Copy link
Contributor Author

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

@aduh95
Copy link
Contributor

aduh95 commented Feb 17, 2022

Looks like the merge commit did some weird stuff, can you do:

git rm bin/companion.js
git checkout main -- README.md

@mifi
Copy link
Contributor Author

mifi commented Feb 17, 2022

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:

"*.md": [

I think we should remove all the --fix and the commands that will mutate, what do you think?

@mifi
Copy link
Contributor Author

mifi commented Feb 17, 2022

Yea it keep modifying readme.md so even after running git checkout main -- README.md and commiting, it will change it back and remove it from the commit

@aduh95
Copy link
Contributor

aduh95 commented Feb 17, 2022

Nah let's keep those --fix, it's less headache to have them than not having them. Why non-fixed code was pushed in the first place is something we need to fix. Probably something related to the release automation is broken.

@mifi
Copy link
Contributor Author

mifi commented Feb 17, 2022

I removed all --fix from eslint and -o from remark and now it works

@mifi
Copy link
Contributor Author

mifi commented Feb 17, 2022

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.

@aduh95
Copy link
Contributor

aduh95 commented Feb 17, 2022

Can you git revert 6eaa516473d4e70a0053b1b4559075a8acacdd0d please?

@aduh95
Copy link
Contributor

aduh95 commented Feb 17, 2022

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.

I guess it could be discussed, but it has little to do with unsplash and should go in its own PR.
FWIW I don't think it's a strong enough case for remove --fix, we have more to gain than to lose from this automatic code fixes IMHO.

@mifi
Copy link
Contributor Author

mifi commented Feb 17, 2022

true, I can create a separate issue about it. but I'm afraid if I revert it now, then readme will be modified again

@mifi
Copy link
Contributor Author

mifi commented Feb 17, 2022

ok I think I managed to push it without running the commit hooks first!

@aduh95
Copy link
Contributor

aduh95 commented Feb 17, 2022

I have a fix PR for the README formatting: #3499

package.json Outdated Show resolved Hide resolved
@arturi arturi merged commit 5cfb9fe into main Feb 17, 2022
@arturi arturi deleted the improve-companion-tests branch February 17, 2022 17:43
github-actions bot added a commit that referenced this pull request Feb 17, 2022
| 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)
HeavenFox pushed a commit to docsend/uppy that referenced this pull request Jun 27, 2023
…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
HeavenFox pushed a commit to docsend/uppy that referenced this pull request Jun 27, 2023
| 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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants