[TBD] Windows platform support to be fixed or not #43
Comments
brodycj
changed the title
|
Marked as TBD for now, as I am not yet ready to confirm this as a decision. Lack of response from the user community on this discussion and on #23 (stable Windows support, with help wanted) makes me even more motivated to drop Windows support. /cc @dlowder-salesforce |
|
I currently have the following two issues on me (CLI support for new Windows native modules):
I was looking into adding it into our own CLI, when I saw that the official RN docs point to this project as the recommended starting point for new native module projects. |
|
Thanks @jonthysell, that would be really nice. I have some more feedback with a couple questions coming next week. |
brodycj
changed the title
|
I have updated the title & description of this issue to better reflect the discussion here. As I said in microsoft/react-native-windows#3201 (comment), I find the separate .NET & C++ implementations to be somewhat problematic to support; I wonder if there may be any way to support both .NET & C++ components for a hopefully limited period of time. Any pointers would be highly appreciated. I would also like to drop RN 0.59 support if possible (see #132). |
|
React Native for Windows vNext will support both C++ and C# components. The default option for creating a new app or module library should also support both C++ and C#. In terms of defaults, we should err towards the most performant option (C++) while still having an option for C# developers as a flag. More context on the other thread: microsoft/react-native-windows#3201 (comment) |
|
Thanks @stmoy for the response. I just added the help wanted label, in case someone wants to contribute a solution. It would be ideal if a solution could support views and example projects, like this utility does for Android and iOS. Another idea could be to make or contribute to a template that supports Android, iOS, and Windows out of the box, kinda like https://github.com/demchenkoalex/react-native-module-template that was suggested in #159 (comment). |
|
One more thing I discovered is that there seems to be now react-native-tscodegen which seems to generate native module code based on TypeScript schema (see #193). If someone truly comes up with a better native module utility than this one it would be really cool 😎 |
OVERVIEW: Windows is no longer supported for reasons discussed in #23 & #43 Moving the existing Windows C# template into `unsupported-platforms`, will continue to be validated by the test suite for now (at least). Removing the `uuid` package dependency which is no longer needed (unless it is used for a supported platform again, someday). Further discussion would be welcome *in a new issue* on GitHub.
* General change notes OVERVIEW: Windows is no longer supported for reasons discussed in #23 & #43 Moving the existing Windows C# template into `unsupported-platforms`, will continue to be validated by the test suite for now (at least). Moving "unsupported-platforms" tests very carefully to preserve the test coverage while avoiding excess test snapshot churn in the git history. Removing the `uuid` package dependency which is no longer needed (unless it is used for a supported platform again, someday). Further discussion would be welcome *in a new issue* on GitHub. * rename & move unsupported Windows C# tests, with updated descriptions (and updated test snapshots) * update Windows windows-csharp tests to test Windows (C#) template only * update windows-csharp test snapshots * remove Windows support from templates/index.js * rename templates/windows.js -> unsupported-platforms/windows-csharp.js * copy templates/.eslintrc.yml into unsupported-platforms * remove use of uuid from lib/lib.js * update CLI error logging test snapshot * remove uuid dependency from package dependencies * update status of Windows platform in README.md * remove obsolete section from README.md * include unsupported-platforms/**/*.js in stryker.conf.js * remove conditional determination of peerDependencies & devDependencies which is no longer needed now that Windows platform support is gone as discovered through mutation testing using Stryker Mutator
|
Windows module support which was only available in C# is now gone due to the difficulties discussed here and in #23. I would be happy to consider supporting Windows again if there is sufficient interest and help from the user community. A new GitHub issue would be appreciated in case of any interest in supporting Windows again. |
|
Hey @brodybits ! Now that things seem to be working, would you object to marking Windows as supported / removing the mention of unsupported on the readme file at the top of the repo? Let me know if there's any blockers that are still applicable. |
|
I just updated README.md according to the current status in this commit: 5554b98 |
|
@brodybits it looks like the readme is still saying Windows is not supported. We are using create-react-native-module on the RNW, side and it seems to work fine. Are there any blockers preventing Windows targets being supported? |
|
This utility does not currently make anything that works on the Windows target platform. It did make something for Windows with C# in the past, but I have disabled this capability. If you want to say that "using create-react-native-module on the RNW, side [...] seems to work fine", it would be awesome if you could give me a pointer how I can reproduce this result. Thanks. |
|
@brodybits see the instructions for creating a Windows native module here: https://microsoft.github.io/react-native-windows/docs/native-modules-setup#creating-a-blank-native-module-project Basically - create a RN module using create-react-native-module, then add Windows to it by using the RNW CLI. |
I am thinking to add a pointer to this: https://microsoft.github.io/react-native-windows/docs/native-modules-setup#creating-a-new-native-module-library-project PR is coming up for you to help review |
At this point I am not convinced whether or not it is worth fixing the Windows platform support (see known issues listed in #23).
This means that I may consider planning to remove support for Windows at some point in the future. Windows support is currently not stable due to some known issues (see #23), and I would see limited commercial motivation to deal with this platform at this point.
Any comments, suggestions, or other feedback from the user community would be much appreciated.
The text was updated successfully, but these errors were encountered: