-
Notifications
You must be signed in to change notification settings - Fork 4.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
Typescript: Exclude native files #21491
Conversation
Size Change: 0 B Total Size: 890 kB ℹ️ View Unchanged
|
There was some prior consideration for this in #18942, though loosely based on problems with the initial setup. I'm not sure if there was an explicit goal in having native code typed as well. |
Thanks Andrew! I had a video call about this with @sirreal yesterday and got his blessing for this approach 😊 (edit: or rather, this approach was suggested by him) The problem is that not only are some of those native implementations more complex than their web counterparts (and thus more work to type), they also import 3rd party packages for which typings might be unavailable. |
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.
Works for me 👍
We took a similar approach for one of ESLint rules: |
I'll add a bit of detail. We were looking into missing type declarations and came across When we investigated, it's used here:
But it's not declared as a dependency of the It is declared in the https://github.com/wordpress-mobile/react-native-svg Are these packages intended to be consumed via npm for react-native projects? If so, I suspect this case is a bug. If not, should the react-native parts of packages even be published? As far as a TypeScript build is concerned (generating type declarations and type checking projects), I don't think there's any way around having web and react-native projects be independent. They would share some files, but the environment is different in ways that we can't expect a single setup to cover everything, certainly not without making big sacrifices in some areas. I'd expect the web build to ignore files like we've done here (native, android, ios). A react-native TypeScript project would need to be a different build. I'm under the impression that gutenberg-mobile is the only consumer of the react-native project and they're not using TypeScript, so we can just focus on web. cc: @SergioEstevao @Tug |
Funny fact when we started the gb-mobile project we wanted to use TypeScript but didn't move forward because the web project was not using and so the benefits were limited. Now that it's looks that the web is moving in that direction we can reevaluate that option. |
Yes, these packages ( |
💯 , let's go for it! Note, I'm not sure what are the subtasks to get this done for the native mobile codepaths, build pipleline and developer tooling, but I understand that we should have the Monorepo first before trying to introduce TS to the native mobile side of things. |
Description
Exclude files ending in
.android.js
,*.ios.js
, and*.native.js
from TypeScript lookup and compilation.This is required for PRs such as #21482 that add types to a package that also has a number of
.native.js
files, unless we also add types to those files (which would significantly increase the workload needed to get our packages typed). However, that doesn't seem to make a lot of sense, since the native modules don't seem to be run through any sort of TypeScript build chain anyway.How has this been tested?
Checklist: