Cli: Support pre-/postlink hooks in autolinking

Created on 14 Jun 2019 · 4Comments · Source: react-native-community/cli

Describe the Feature

Currently prelink and postlink are not executed when autolinking happens. That's because the linking logic moved to CocoaPods and Gradle scripts.

Possible Implementations

Hooks should be available in config already: https://github.com/react-native-community/cli/blob/7dec6541a88ba3496d43a20a832b3150166522aa/types/index.js#L123-L127

Hope @orta and @Salakar have ideas on how to support these on per-platform level.

autolink feature request

Source

thymikee

👍7

Most helpful comment

I was thinking for this topic for a while recently and I'm considering killing prelink/postlink hooks in the CLI (by not supporting them in autolinking). It occurs to me that the whole concept is not so good after all, even if helpful at times. Here's the list of pain points I have with these "hooks":

incoherent DX – some do background work, some ask questions, some run even when already linked,
potential for security vulnerabilities – can do virtually anything without users realizing, e.g. running arbitrary commands or tracking scripts (could be fixed with a direct question whether to run the hook, but still),
incompatible with autolinking design – they run pre/post "linking" phase which was triggered for all all platforms at once using a command, while autolinking is per-platform during buildtime, which means to stay backwards compatible CLI would run Android-related changes when doing "pod install" (no way to distinguish as it's all in single script file)
often misused to hack/workaround CLI limitations/bugs – potential for over-complicating user code by e.g. editing native build files, which makes it even harder for users to upgrade, since the code was added automatically, causing FUD if user is not experienced with native tooling

Saying all that, a vast majority of the existing postlink hooks is either being obsolete with autolinking and general improvements to the CLI and default RN template or can be trimmed down in scope and quite easily swapped by a comprehensive docs, which I'm probably willing to contribute for some more popular packages. Feel free to change my mind!

thymikee on 22 Jun 2019

👍3

All 4 comments

incoherent DX – some do background work, some ask questions, some run even when already linked,
potential for security vulnerabilities – can do virtually anything without users realizing, e.g. running arbitrary commands or tracking scripts (could be fixed with a direct question whether to run the hook, but still),
incompatible with autolinking design – they run pre/post "linking" phase which was triggered for all all platforms at once using a command, while autolinking is per-platform during buildtime, which means to stay backwards compatible CLI would run Android-related changes when doing "pod install" (no way to distinguish as it's all in single script file)
often misused to hack/workaround CLI limitations/bugs – potential for over-complicating user code by e.g. editing native build files, which makes it even harder for users to upgrade, since the code was added automatically, causing FUD if user is not experienced with native tooling

thymikee on 22 Jun 2019

👍3

In their current form and implementation, I considered them deprecated and that was one of the reasons I didn't push on implementing them as a part of autolinking which should solve the primary use-case for them.

I am generally in favour of leaving them as a thing of the past and not adding support for the future linking.

One thing that I would like to make sure though is whether consumers of the CLI, such as Ignite (CC: @jamonholmgren) are taking advantage of that and if yes, what does it look like.

We should probably come up with a better mechanism if needed to support hooking into the lifecycle.

grabbou on 24 Jun 2019

👍1

I haven't really thought through the implications of the changes you've done, yet; right now I'm focused on the Bowser boilerplate more than Ignite CLI. I'll probably shift back sometime later this year.

jamonholmgren on 14 Jul 2019

Post link hooks are still useful. As far I know there is not possible autolink more then one gradle project/submodule within single react-native plugin.

Consider you have rn plugin that consist of two gradle projects/submodules. So app project using this plugin would be:

:app: 
:plugin1_submodule1
:plugin1_submodule2

And plugin1_submodule1 can depend on plugin1_submodule2( but that's not relevant here). I believe currently you can only autolink one module.

In previous version, I've used postlink script and link the other submodule, using patch scripts, that were part of RN itself (now part of react-native-community).