Adds packager configuration to support windows platform

[rozele]

This pull request is a prerequisite to enabling the react-native-windows platform extension.

In the Resolver component, we need to add 'windows' to the list of platforms that are allowed in the DependencyGraph. We also need to add 'react-native-windows' (the name of the Windows platform extension NPM module) to the providesModuleNodeModules option. This allows the node_module folder check in the DependencyGraphHelper from node-haste to be bypassed for *.windows.js files in the Windows NPM package.

For good measure, I also included a change to blacklist.js to ensure .windows.js files are ignored when the packager is parameterized on a platform.

[ghost]

By analyzing the blame information on this pull request, we identified @davidaurelio and @cpojer to be potential reviewers.

[bestander]

Looks reasonable

[bestander]

Really looking forward to try that on my Surface Pro 👍

[ide]

Mostly looks good to me. Generally we don't want to add entries to providesModuleNodeModules but it probably makes sense to make an exception solely for RN Windows. The thing we don't want is for this array to grow into "RN for [every platform]". cc @vjeux

[rozele]

I'm also open to any re-architecture suggestions @ide. I think it would be great to see a configuration based approach, where the end user specifies which platforms are enabled (both here and in my node-haste PR: facebookarchive/node-haste#70) and which node_modules directories are allowed in haste. Eliminating as much of this static config as possible.

[ide]

Yep I think that's the plan. But RN Windows is the one project that we might want to make a temporary exception for.

[mkonicek]

Tests passed, let's shipit :)

@facebook-github-bot shipit

[ghost]

Thanks for importing. If you are an FB employee go to Phabricator to review.

[davidaurelio]

providesModuleNodeModules is going away.

but it probably makes sense to make an exception solely for RN Windows.

and every other platform coming along? Can we come up with better ideas, please?

[mkonicek]

Just talked to @davidaurelio - we should eventually remove providesModuleNodeModules from the packager completely, have to come up with the right approach. For now we can keep this PR.

[davidaurelio]

@ok, I tried to come up with something that might scale better:

what if the packager reads react-native-<platform>/package.json, and we read a mapping from there? "react-native" is already taken. Let’s assume "react-native-override".

It could look like this:

package.json

{ "name": "react-native-windows",
  "react-native-override": {
    "View": "lib/View.js",
    "Text": "lib/Text.js" } }

[rozele]

I presume there is some implied convention here that the DependencyGraph would use the part of react-native-<platform> as the module map platform key? What if a particular package contained multiple platform implementations for whatever reason? Maybe it just needs to be more verbose...

{ 
  "name" : "react-native-windows",
  "react-native-overrides" : {
    "windows" : {
      "Text": "lib/Text.windows.js"
    },
    "foo" : {
      "Text": "lib/Text.foo.js"
    }
  }
}

[davidaurelio]

What if a particular package contained multiple platform implementations for whatever reason?

Do you have a specific scenario in mind? I’d like to keep it simple/separated, but maybe that’s to simplistic?

[ide]

and every other platform coming along?

No, only Microsoft. We've rejected at least one other PR of this nature in the past. I just think that with the effort behind RN Windows and the fact that it's the primary focus of a couple engineers, it's the one time we should make a (temporary) exception.

[davidaurelio]

I just have mixed feelings, because making this exceptions means it’s going to stay. I wanted to kill that feature in the next weeks, but that’s not going to happen now.

[rozele]

@davidaurelio, totally agree that this is not the cleanest approach, and I'd also like to see something better. It would be great for someone with much more experience with the packager to put a PR together, this was just the quickest way to unblock publishing a windows package for now, and it didn't seem much different from the 'web' platform stuff that's sprinkled throughout the packager but doesn't have any local backing code.

I think this change can and should definitely be temporary. Don't feel blocked on removing the providesModuleNodeModules feature at will, so long as an alternative for overriding modules from other packages is added in simultaneously ;-).