Add typings for the getConfiguration method

[fbartho]

trafficstars

getConfiguration is useful for displaying which deploymentKey / Deployment Channel is currently configured for the running app.

This is one of many methods exposed here: https://github.com/microsoft/react-native-code-push/blob/master/CodePush.js#L609 in the JS but that didn't have JS Typings Provided.

Please let me know:

1. if the remaining methods should be added.
2. if you want to have a set of string constants vended via the RN constantsToExport API instead. (the keys on nativeConfiguration are the direct raw keys vended from the API). This would be much less ergonomic in the normal case because it would force devs to use a dictionary-lookup strategy, and it would be clunkier to write typings for, but it has the added benefit of being more resilient if these API keys change over time.

[fbartho]

Related PR: #2093

[velimir-jankovic]

Can you please describe your use case? Why would you want to get current deploymentKey as it would already be known?

This API is not meant for use by developers, but if there's legitimate use case we can consider.

[Droidking18]

@velimir-jankovic if it's set natively, with an environment variable and we just want to ensure its truthy before running sync?

[fbartho]

@velimir-jankovic getting the current deployment key would help with distinguishing debug builds.

Since the information is available at runtime, setting the typings just provides the same value for typescript coders, that JavaScript users can see.

I understand if your position is that this should be private API, but then I’d hide the API entirely.

I’m going to close this PR, as it’s completely stale, and I have moved on. Despite me appreciating the code in this repository, I don’t recommend code-push-style technology for any companies I consult for, as it brings a boatload of native-dependency, operational, deployment, and customer support complexity. Unless your company is at Microsoft-scale, with freestanding build-infrastructure-services team to build and manage all the pipelines and deployments, I would stay away.

[As an example: it encourages teams to never update their dependencies, because it’s a challenge to figure out if those dep-updates change something that requires native-compilation. The only code-pushable dep-updates are ones that are JS-only updates. Additionally, using code-push combinatorically increases the possible states of a given device unless you’re brutally restrictive in your pipeline configuration (which then defeats the purpose of code-push)]

Two cases where code-push may be great:

• Huge company with large service team that can manage code-push, continuous integration, QA, and dependency updates. New native builds are constantly being submitted that bake in the code-push updates, so code-push only serves for major-oops bug-fixing, and “same-day” feature releases (the latter of which is a violation of iOS review-procedures).
• Single person company, where all the state can be kept in your head (and where Apple is unlikely to punish you for launching features bypassing App Review).