launchdarkly / ld-find-code-refs

Build tool for automatically sending feature flag code references to LaunchDarkly
https://launchdarkly.com
Other
45 stars 34 forks source link

Possible to use no delimiters? #347

Closed HeyParkerJ closed 9 months ago

HeyParkerJ commented 1 year ago

Hi team - I've been working on implementing ld-find-code-refs in my organization, and I've run into an issue where it doesn't seem to find our flag references because none of them are wrapped in one of the out-of-the-box delimiters (we are de-structuring them using the React SDK useFlags like so: const { myFlag } = useFlags();. Is there a way to configure the tool to not require any delimiters and merely find the references via the generated aliases? The current docs seem to indicate that all one can do is disable all default delimiters and specify other delimiters, but nothing about not using delimiters.

Thanks, Parker

jazanne commented 1 year ago

@HeyParkerJ The tool should be able to find those react aliases by adding camelcase alias to your configuration file https://github.com/launchdarkly/ld-find-code-refs/blob/main/docs/ALIASES.md#flag-keys-transposed-to-common-casing-conventions.

Any aliases that are searched for don't require delimiters. Delimiters are only used when searching for "raw" flag keys

Do you already have that alias configured?

HeyParkerJ commented 1 year ago

Hi @jazanne - thanks for the super speedy reply!

That's interesting - after some further testing I think there might be another problem at play then. I'll list everything I have going on/configured to see if there's anything obvious before I attempt to do a full repro.

.launchdarkly/coderefs.yaml (this config is currently just casting a really wide net - def can be parsed down once this starts working - I've done many variations of this configuration thusfar)

aliases:
  - type: camelcase
  - type: pascalcase
  - type: snakecase
  - type: uppersnakecase
  - type: kebabcase
  - type: dotcase
  - type: literal
    flags:
      MY_FLAG:
        - myFlag

project/components/MyComponent.tsx

...
  const { myFlag } = useFlags();
  const renderFlagStuff = () => {
    if (myFlag) {
...

The command I'm running: ld-find-code-refs --projKey=my-project --repoName='my-repo' --debug --dir='.' --defaultBranch='master'

What seems to be the main piece of output I'm getting from debug (I've been wondering if 0 files should be reading something like 500 files if it were scanning the repo correctly): INFO: 2023/04/28 12:43:13 coderefs.go:148: sending 0 code references across 14 flags and 0 files to LaunchDarkly for project(s): [ my-project]

Running:

ld-find-code-refs version 2.10.0
M1 MacBook Pro running Ventura 13.3.1
jazanne commented 1 year ago

Thanks for sharing these additional details.

does myFlag exist in the project (my-project) you are running against? The way the tool works, it will only search for flags that it knows exist, regardless of alias configuration.

HeyParkerJ commented 1 year ago

In this example, the flag is named MY_FLAG within my-project - does the flag need to be camelCase inside LaunchDarkly as well?

jazanne commented 1 year ago

No, the flag shouldn't need to be camel-cased in LaunchDarkly since aliases are configured.

We'll have the team look at this and see if we can find the issue. Sorry for the inconvenience

HeyParkerJ commented 1 year ago

No worries at all, thanks for taking a look! One thing that might be useful from my end is if the debug flag output more information as it scanned the files - I can't really confirm or deny if my project is being scanned correctly with the current output - and sadly I'm woefully ignorant to how I'd recompile the tool after adding further debugs in Golang.

From my end - I can attempt to create a small repro if that would be useful - that being said, that does seem a little cumbersome considering that it'll need to hook into my organization's LaunchDarkly instance. Let me know if that's the direction we should go and I'll find time to figure it out.

jazanne commented 1 year ago

@HeyParkerJ Thanks for your patience as we look into this.

We have identified two underlying issues that are affecting alias parsing for your flag keys

  1. There is a known issue with the library we use for converting keys that means screaming snake case like MY_FLAG isn't properly converted to camelcase
  2. For the literal alias you set up, the library we use isn't preserving the uppercase case key MY_FLAG so it's not identifying the alias myFlag you have configured.

I would like to find a solution to both of these issues, but in the meantime, is there a particular reason that you are choosing to use screaming snake case for flag keys? I believe if you can switch to a regular snakecase this should eliminate alias issues.

jazanne commented 9 months ago

@HeyParkerJ not sure if you ever got a workaround for this issue, but I wanted to let you know that flags with key in screaming snakecase will now properly convert to camelcase

See demo here https://github.com/launchdarkly/ld-find-code-refs/pull/399