-
Notifications
You must be signed in to change notification settings - Fork 24.3k
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
Add support for out-of-tree platform plugins #20825
Conversation
local-cli/core/findPlugins.js
Outdated
@@ -71,11 +98,12 @@ const findPluginInFolder = folder => { | |||
if (pkgJson) { | |||
commands = commands.concat(findPluginsInReactNativePackage(pkgJson)); |
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.
prettier/prettier: Delete ··
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 am not entirely sure what this means
[/^(.*)\.(android|ios|native|web|windows|dom)$/, '$1'], | ||
// strip platform suffix | ||
[/^(.*)\.(android|ios|native)$/, '$1'], | ||
// strip plugin platform suffixes |
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.
prettier/prettier: Insert ,
@rozele: I had to change around the lines you modified in #20705 because it seems like |
local-cli/core/findPlugins.js
Outdated
haste.providesModuleNodeModules.concat(pkgHaste.providesModuleNodeModules); | ||
} | ||
}; | ||
|
||
const findPluginInFolder = folder => { |
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.
prettier/prettier: Replace flatten(plugins.map(p·=>·p.haste.providesModuleNodeModules))
with ⏎········flatten(plugins.map(p·=>·p.haste.providesModuleNodeModules)),⏎······
@rozele @vincentriemer @CaptainNic I’m closing #20662 in favor of this approach. |
RNTester/js/ImageExample.js
Outdated
}]} | ||
style={[ | ||
styles.base, | ||
styles.leftMargin, |
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.
react-native/no-inline-styles: Inline style: { borderWidth: 5,
borderTopLeftRadius: 10,
borderTopRightRadius: 20,
borderBottomRightRadius: 30,
borderBottomLeftRadius: 40,
borderColor: 'red' }
|
||
const NativeEventEmitter = require('NativeEventEmitter'); | ||
|
||
module.exports = new NativeEventEmitter('StatusBarManager'); |
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.
Cannot call NativeEventEmitter
with 'StatusBarManager'
bound to nativeModule
because string [1] is incompatible with NativeModule
[2].
b5d5865
to
e52ce92
Compare
RNTester/js/ImageExample.js
Outdated
}]} | ||
style={[ | ||
styles.base, | ||
styles.leftMargin, |
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.
react-native/no-inline-styles: Inline style: { borderWidth: 5,
borderTopLeftRadius: 10,
borderTopRightRadius: 20,
borderBottomRightRadius: 30,
borderBottomLeftRadius: 40,
borderColor: 'red' }
e52ce92
to
92c1b7b
Compare
I've added a dummy platform in Currently, there is just a test in I currently have this module on NPM for testing purposes that I could transfer ownership over if FB devs are interested: |
I've added an entry to package.json that installs this local module using this syntax:
Which was sufficient for letting me get a |
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.
Mostly questions and minor styling. Fantastic work on adding unit and e2e tests at the same time! 🥇
|
||
class DummyProgressViewIOS extends React.Component { | ||
render() { | ||
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.
why not just have the render throw("Not implemented") or something similar? or just export require('UnimplementedView');
like the other files?
class DummySegmentedControlIOS extends React.Component { | ||
render() { | ||
return ( | ||
<View style={[styles.dummy, this.props.style]}> |
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.
same question here -- why not just throw?
|
||
'use strict'; | ||
|
||
module.exports = {}; |
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.
why empty here and not require('UnimplementedView');
as elsewhere?
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.
StatusBarIOS isn't a React component
None if this code will be ran at all at any point - it is purely for the bundler's sake, so the actual code isn't that important. A lot of the shims, like DummySegmentedControlIOS
are just copied over from Android shims in the RN codebase. Sorry for not making this clearer! I'll edit the main post
'use strict'; | ||
|
||
// Completely empty shim for the sake of bundling. | ||
const Settings = {}; |
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.
if require('UnimplementedView');
can't work here, let's inline the assignment as elsewhere.
52356b9
to
7c013d6
Compare
I've run unit tests on my fork on a branch that's been rebased against #20854, and it turns out that
I honestly can't think of a way to get around this, so I will be trying this again as a separate pull request. If anyone wants to peek around at the code, it still exists at this branch: https://github.com/empyrical/react-native/tree/haste-plugins-plus-test |
@empyrical I think have run across this before. I was trying to do module substitution to emulate tree shaking for an out-of-tree platform. My approach used the I'm by no means a Metro expert, but I've done a bit of hacking lately with it. Cheers, and I'll take a look at your fork as well to see what I see. -Jeff |
@rozele @vincentriemer I'd love to hear your feedback on this, seems solid - and thanks for adding the tests too! |
I’ll try and take a look tonight 👌 |
Short of actually pulling the branch and testing it against rndom itself, LGTM 👍 |
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.
Test failures seem unrelated to this PR.
2a83371
to
3a3bda4
Compare
b0e7305
to
a73d991
Compare
}, | ||
|
||
getProvidesModuleNodeModules(): Array<string> { | ||
return ['react-native', 'react-native-windows', 'react-native-dom']; | ||
return ['react-native', ...plugins.haste.providesModuleNodeModules]; | ||
}, |
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.
prettier/prettier: Replace ·config.resolver.providesModuleNodeModules·||
with ⏎····config.resolver.providesModuleNodeModules·||⏎···
}, | ||
|
||
getProvidesModuleNodeModules(): Array<string> { | ||
return ['react-native', 'react-native-windows', 'react-native-dom']; | ||
return ['react-native', ...plugins.haste.providesModuleNodeModules]; | ||
}, |
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.
prettier/prettier: Replace ·config.resolver.providesModuleNodeModules·||
with ⏎····config.resolver.providesModuleNodeModules·||⏎···
}, | ||
|
||
getProvidesModuleNodeModules(): Array<string> { | ||
return ['react-native', 'react-native-windows', 'react-native-dom']; | ||
return ['react-native', ...plugins.haste.providesModuleNodeModules]; |
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.
prettier/prettier: Insert ⏎···
Rebased against |
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.
hramos is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
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.
hramos is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
@empyrical merged commit 03476a2 into Once this commit is added to a release, you will see the corresponding version tag below the description at 03476a2. If the commit has a single |
Summary: This pull request adds the ability for a platform developer to provide a `"haste"` key under the `"rnpm"` key in their `package.json` which allows the packager to pick up that platform's javascript files. The intent is to remove the need to have custom platforms hardcoded in. This is inspired by the `"jest": { "haste": {} }` key used by jest. For example, React Native Dom would have an entry like: ```json { "rnpm": { "haste": { "providesModuleNodeModules": [ "react-native-dom" ], "platforms": [ "dom" ] } } } ``` Support for more keys (path blacklists perhaps?) could be added in the future. This succeeds #20662, as per a discussion I had with matthargett. I've got an open discussion over here as well: react-native-community/discussions-and-proposals#21 Pull Request resolved: #20825 Differential Revision: D9596429 Pulled By: hramos fbshipit-source-id: a02f0da0bea8870bdc45d55e23da8ccbc36249f2
Summary: This pull request adds the ability for a platform developer to provide a `"haste"` key under the `"rnpm"` key in their `package.json` which allows the packager to pick up that platform's javascript files. The intent is to remove the need to have custom platforms hardcoded in. This is inspired by the `"jest": { "haste": {} }` key used by jest. For example, React Native Dom would have an entry like: ```json { "rnpm": { "haste": { "providesModuleNodeModules": [ "react-native-dom" ], "platforms": [ "dom" ] } } } ``` Support for more keys (path blacklists perhaps?) could be added in the future. This succeeds facebook#20662, as per a discussion I had with matthargett. I've got an open discussion over here as well: react-native-community/discussions-and-proposals#21 Pull Request resolved: facebook#20825 Differential Revision: D9596429 Pulled By: hramos fbshipit-source-id: a02f0da0bea8870bdc45d55e23da8ccbc36249f2
Summary: This pull request adds the ability for a platform developer to provide a `"haste"` key under the `"rnpm"` key in their `package.json` which allows the packager to pick up that platform's javascript files. The intent is to remove the need to have custom platforms hardcoded in. This is inspired by the `"jest": { "haste": {} }` key used by jest. For example, React Native Dom would have an entry like: ```json { "rnpm": { "haste": { "providesModuleNodeModules": [ "react-native-dom" ], "platforms": [ "dom" ] } } } ``` Support for more keys (path blacklists perhaps?) could be added in the future. This succeeds facebook#20662, as per a discussion I had with matthargett. I've got an open discussion over here as well: react-native-community/discussions-and-proposals#21 Pull Request resolved: facebook#20825 Differential Revision: D9596429 Pulled By: hramos fbshipit-source-id: a02f0da0bea8870bdc45d55e23da8ccbc36249f2
Summary: This pull request adds the ability for a platform developer to provide a `"haste"` key under the `"rnpm"` key in their `package.json` which allows the packager to pick up that platform's javascript files. The intent is to remove the need to have custom platforms hardcoded in. This is inspired by the `"jest": { "haste": {} }` key used by jest. For example, React Native Dom would have an entry like: ```json { "rnpm": { "haste": { "providesModuleNodeModules": [ "react-native-dom" ], "platforms": [ "dom" ] } } } ``` Support for more keys (path blacklists perhaps?) could be added in the future. This succeeds #20662, as per a discussion I had with matthargett. I've got an open discussion over here as well: react-native-community/discussions-and-proposals#21 Pull Request resolved: facebook/react-native#20825 Differential Revision: D9596429 Pulled By: hramos fbshipit-source-id: a02f0da0bea8870bdc45d55e23da8ccbc36249f2
Taken from: facebook/react-native@03476a2 Summary: This pull request adds the ability for a platform developer to provide a `"haste"` key under the `"rnpm"` key in their `package.json` which allows the packager to pick up that platform's javascript files. The intent is to remove the need to have custom platforms hardcoded in. This is inspired by the `"jest": { "haste": {} }` key used by jest. For example, React Native Dom would have an entry like: ```json { "rnpm": { "haste": { "providesModuleNodeModules": [ "react-native-dom" ], "platforms": [ "dom" ] } } } ``` Support for more keys (path blacklists perhaps?) could be added in the future. This succeeds #20662, as per a discussion I had with matthargett. I've got an open discussion over here as well: react-native-community/discussions-and-proposals#21 Pull Request resolved: facebook/react-native#20825 Differential Revision: D9596429 Pulled By: hramos fbshipit-source-id: a02f0da0bea8870bdc45d55e23da8ccbc36249f2
Taken from: facebook/react-native@03476a2 Summary: This pull request adds the ability for a platform developer to provide a `"haste"` key under the `"rnpm"` key in their `package.json` which allows the packager to pick up that platform's javascript files. The intent is to remove the need to have custom platforms hardcoded in. This is inspired by the `"jest": { "haste": {} }` key used by jest. For example, React Native Dom would have an entry like: ```json { "rnpm": { "haste": { "providesModuleNodeModules": [ "react-native-dom" ], "platforms": [ "dom" ] } } } ``` Support for more keys (path blacklists perhaps?) could be added in the future. This succeeds #20662, as per a discussion I had with matthargett. I've got an open discussion over here as well: react-native-community/discussions-and-proposals#21 Pull Request resolved: facebook/react-native#20825 Differential Revision: D9596429 Pulled By: hramos fbshipit-source-id: a02f0da0bea8870bdc45d55e23da8ccbc36249f2
Taken from: facebook/react-native@03476a2 Summary: This pull request adds the ability for a platform developer to provide a `"haste"` key under the `"rnpm"` key in their `package.json` which allows the packager to pick up that platform's javascript files. The intent is to remove the need to have custom platforms hardcoded in. This is inspired by the `"jest": { "haste": {} }` key used by jest. For example, React Native Dom would have an entry like: ```json { "rnpm": { "haste": { "providesModuleNodeModules": [ "react-native-dom" ], "platforms": [ "dom" ] } } } ``` Support for more keys (path blacklists perhaps?) could be added in the future. This succeeds #20662, as per a discussion I had with matthargett. I've got an open discussion over here as well: react-native-community/discussions-and-proposals#21 Pull Request resolved: facebook/react-native#20825 Differential Revision: D9596429 Pulled By: hramos fbshipit-source-id: a02f0da0bea8870bdc45d55e23da8ccbc36249f2
Taken from: facebook/react-native@03476a2 Summary: This pull request adds the ability for a platform developer to provide a `"haste"` key under the `"rnpm"` key in their `package.json` which allows the packager to pick up that platform's javascript files. The intent is to remove the need to have custom platforms hardcoded in. This is inspired by the `"jest": { "haste": {} }` key used by jest. For example, React Native Dom would have an entry like: ```json { "rnpm": { "haste": { "providesModuleNodeModules": [ "react-native-dom" ], "platforms": [ "dom" ] } } } ``` Support for more keys (path blacklists perhaps?) could be added in the future. This succeeds #20662, as per a discussion I had with matthargett. I've got an open discussion over here as well: react-native-community/discussions-and-proposals#21 Pull Request resolved: facebook/react-native#20825 Differential Revision: D9596429 Pulled By: hramos fbshipit-source-id: a02f0da0bea8870bdc45d55e23da8ccbc36249f2
Summary: This pull request adds the ability for a platform developer to provide a `"haste"` key under the `"rnpm"` key in their `package.json` which allows the packager to pick up that platform's javascript files. The intent is to remove the need to have custom platforms hardcoded in. This is inspired by the `"jest": { "haste": {} }` key used by jest. For example, React Native Dom would have an entry like: ```json { "rnpm": { "haste": { "providesModuleNodeModules": [ "react-native-dom" ], "platforms": [ "dom" ] } } } ``` Support for more keys (path blacklists perhaps?) could be added in the future. This succeeds facebook#20662, as per a discussion I had with matthargett. I've got an open discussion over here as well: react-native-community/discussions-and-proposals#21 Pull Request resolved: facebook#20825 Differential Revision: D9596429 Pulled By: hramos fbshipit-source-id: a02f0da0bea8870bdc45d55e23da8ccbc36249f2
Summary: This pull request adds the ability for a platform developer to provide a `"haste"` key under the `"rnpm"` key in their `package.json` which allows the packager to pick up that platform's javascript files. The intent is to remove the need to have custom platforms hardcoded in. This is inspired by the `"jest": { "haste": {} }` key used by jest. For example, React Native Dom would have an entry like: ```json { "rnpm": { "haste": { "providesModuleNodeModules": [ "react-native-dom" ], "platforms": [ "dom" ] } } } ``` Support for more keys (path blacklists perhaps?) could be added in the future. This succeeds facebook#20662, as per a discussion I had with matthargett. I've got an open discussion over here as well: react-native-community/discussions-and-proposals#21 Pull Request resolved: facebook#20825 Differential Revision: D9596429 Pulled By: hramos fbshipit-source-id: a02f0da0bea8870bdc45d55e23da8ccbc36249f2
This pull request adds the ability for a platform developer to provide a
"haste"
key under the"rnpm"
key in theirpackage.json
which allows the packager to pick up that platform's javascript files. The intent is to remove the need to have custom platforms hardcoded in. This is inspired by the"jest": { "haste": {} }
key used by jest.For example, React Native Dom would have an entry like:
Support for more keys (path blacklists perhaps?) could be added in the future.
This succeeds #20662, as per a discussion I had with @matthargett.
I've got an open discussion over here as well: react-native-community/discussions-and-proposals#21
Test Plan:
I've modified a local copy of RNDom to have the above example in its
package.json
in an unmodified default React Native app project, and a JS bundle was build successfully.Release Notes:
[CLI] [ENHANCEMENT] [local-cli/core/findPlugins.js] - Modified the
findPlugins
function to handle this newhaste
field[CLI] [ENHANCEMENT] [local-cli/core/index.js] - Removed the hardcoded platforms and switched to use output from
findPlugins