Migrate to TypeScript
planned
Gustavo
I'm using the v6 and TS typings are a bit broken. I think migrating the source code to TypeScript could help in many aspects:
- Immediately catch type errors;
- More signal, less noise (because a lot of duck typing won't be needed anymore);
- Self-documenting nature of static typing will make it a lot easier for other people to contribute;
- Less chances of accidentally breaking things during refactorings.
Those are only some of the benefits. There are other less important ones like better IDE experience and not needing to keep separate, unsynced d.ts files. If you think it's a good idea, I may be able to help with PRs.
Stanislav Shakirov
https://github.com/invertase/react-native-firebase/issues/2614
This bug is very annoying. I had to provide fixed type definition for each of the sub-components.
Mike Diarmid
planned
Mike Diarmid
This is on the roadmap for after v6 already, the reason we didn't do it immediately was so as not to slow down the v5 -> v6 codebase migration - e.g. we're 8 months in already.
The latest version of v6 alphas have type testing files now and there shouldn't be many type related issues (if any) - unpublished, but if we don't know about them then we can't fix it. If you find some issues feel free to fork, add the broken types to the relevant type-test file so that it shows the broken behaviour, submit a PR and we can look at fixing it (or send a fix as well).
Example type-test: https://github.com/invertase/react-native-firebase/blob/master/packages/app/type-test.ts
The other reason is that we still need a separate type def file per module anyway as the new docs are generated from these, so even if we migrate we'd still need these type def files separate and in the format they currently are.
---
For reference, here's the
post-v6
actions board: https://github.com/invertase/react-native-firebase/projects/4Mike Hardy
I personally use typescript also so I'm +1 but there are disadvantages too - i.e.does git blame work across .js to .ts changes? time required, getting sourcemaps right (already a challenge). I'm still +1 but it's not a magical typescript garden on the other side of the wall, just slightly greener grass
Gustavo
Mike Hardy: Hey Mike, could you explain the issue with the source maps?
Mike Hardy
Gustavo: you get a redbox on your emulator/simulator, is it correctly displaying the typescript positions in the real source files for you? the same in your crashlytics reports? If so, where's the single coherent document that states exactly how to set that up (this is sort of a trick question - maybe I'm just inexperienced, but I don't think it exists?)
Gustavo
Mike Hardy: Not sure about that, and I'm not using Crashlytics yet, but I'm also not sure whether the library consumer cares about source maps of libraries. I mean, usually the lib consumer will care only with lines inside his own
src
folder, not from the lines inside node_modules
. So maybe it's not a huge problem if we can't manage to get good source mapping?Mike Hardy
Gustavo: I'm +1 either way, I just always have half smile when I see people list all the pros, no mention of cons. Devils advocate ;-)