feat(gatsby-source-filesystem): add optional name parameter to createRemoteFileNode

[oorestisime]

Fix: #11037

Description

Take an optional name parameter to fix issue with temporary urls having no "guessable" name

Related Issues

[sidharthachatterjee]

Thank you for this, @oorestisime

Would you like to also add a test or two to assert this behaviour and ensure we don't see a regression again? 🙂

[oorestisime]

Thank you for this, @oorestisime

Would you like to also add a test or two to assert this behaviour and ensure we don't see a regression again? slightly_smiling_face

I would really like to do so but for this particular package it is always hard, at least for me. There are a lot of mocks to do and basically i am not sure how do to do so (plus there are not many in place to get inspired). If you have an example in mind i can work on it probably.

[sidharthachatterjee]

@oorestisime So in packages/gatsby-source-filesystem/src/__tests__/create-remote-file-node.js you could add a test asserting overrides name if passed in

In this you would pass in a name and a url and assert that createNode got called with the right one

Check out the documentation at https://jestjs.io/docs/en/mock-functions for how to listen on arguments a mock fn is called with

[oorestisime]

But until now these tests were not entering here https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-filesystem/src/create-remote-file-node.js#L180-L262

and there i need to mock requestRemoteNode etc. what if i change getRemoteFileName to take as parameters a url and optionnaly a name. so that i could indeed unit-test only that part?

[DSchau]

@sidharthachatterjee it's fairly challenging to test this in a clean way. We can mock--but we need to mock quite a bit, and then those test(s) will likely become a little fragile and will require a fair amount of tweaking when we make changes to this functionality.

It would be excellent if we can perhaps refactor this a bit to enable easier unit testing (and cleaner code!), but I don't think that should be a blocker to merging this PR. That being said--subequent PRs addressing some of the things we're talking about here would be 👌

Thanks to both of you!

[DSchau]

Successfully published:
 - [email protected]