Better support for custom file extensions (and build flavours)

[EdenGottlieb]

Motivation

This PR solves the following issue in the metro-bundler:
facebook/metro#17

This PR was created to enhance support for custom file extensions - mainly, enabling it to be used for build flavouring.

In the current configuration, custom file extensions are concatenated to the existing ones.
This causes files which match *.js to always override files with custom file extensions such as *.e2e.js.
This behaviour contradicts the specification of a custom file extension, which expresses a desire to use the file with the custom extension instead of the regular .js, when possible.

This is useful for several use cases, such as defining specialised files to be loaded in End-To-End testing or bundling different build flavours of your app (such as "Free" or "Premium" flavours).

Note:
This change is not a breaking change, since it alters behaviour for files matching*.ext.js while specifying a custom source extension ext.js. This is currently not supported in any way (the *.js will override the custom ones) , so nothing will break.

This change does not break specifying different files for different platform, because files are searched for using ${fileNamePrefix}.${platform}.${ext}. Specifying a custom extension e2e.js will load index.ios.e2e.js and index.android.e2e.js for iOS and Android respectively, while index.ios.js and index.android.js, index.native.js (if specified), and index.js while be used as fallbacks as usual.

Test Plan

At the moment, this file has no test plan, and there's no way of testing the altered logic without running an End-To-End test for the server. This will alter the test behaviour in a significant way, so was not implemented without further planning.

Release Notes

[CLI] [ENHANCEMENT] [local-cli/server] - Support build flavouring (Place custom source extensions in front of default ones).

[facebook-github-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need the corporate CLA signed.

If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[EdenGottlieb]

@DanielZlotin

[facebook-github-bot]

@EdenGottlieb I tried to find reviewers for this pull request and wanted to ping them to take another look. However, based on the blame information for the files in this pull request I couldn't find any reviewers. This sometimes happens when the files in the pull request are new or don't exist on master anymore. Is this pull request still relevant? If yes could you please rebase? In case you know who has context on this code feel free to mention them in a comment (one person is fine). Thanks for reading and hope you will continue contributing to the project.

[facebook-github-bot]

@EdenGottlieb I tried to find reviewers for this pull request and wanted to ping them to take another look. However, based on the blame information for the files in this pull request I couldn't find any reviewers. This sometimes happens when the files in the pull request are new or don't exist on master anymore. Is this pull request still relevant? If yes could you please rebase? In case you know who has context on this code feel free to mention them in a comment (one person is fine). Thanks for reading and hope you will continue contributing to the project.

[jeanlauliac]

This change is not a breaking change, since it alters behaviour for files matching*.ext.js while specifying a custom source extension ext.js. This is currently not supported in any way (the *.js will override the custom ones) , so nothing will break.

It is a breaking change: if someone had 2 files foo.ext.js and foo.js and wanted the last one to be picked up, with this change the first one will get resolved instead. But, I do agree this use case should be minimal, if not inexistent.

[jeanlauliac]

Ah let me look into rebasing this correctly, I didn't realise this PR months old, and a bunch of code has changed since then :) Thank you @vjeux for bringing it to my attention.

[DanielZlotin]

This can be closed as the code landed in 0.55 as far as I can tell. Thanks

[rotemmiz]

This diff was added through a different commit, please close this PR as this issue is now resolved.