chore: typeScript generation specification

[akashrpo]

🔒 Scanned for secrets using gitleaks 8.28.0

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 46.21%. Comparing base (6bf74c3) to head (0132715).
⚠️ Report is 9 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #317      +/-   ##
==========================================
+ Coverage   45.50%   46.21%   +0.71%     
==========================================
  Files         179      179              
  Lines       12881    12960      +79     
==========================================
+ Hits         5862     5990     +128     
+ Misses       6483     6432      -51     
- Partials      536      538       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sonarqubecloud]

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[saikumarrs]

Screen events are not supported by JS SDK. Instead, we support page events.

[fxenik]

Let's see if we can avoid global here and instead use the RudderAnalytics object exposed by the javascript SDK. That would probably require the Typer Analytics object to be defined with as a class with a constructor, and instantiated with new TyperAnalytics (or similar) after the new RudderAnalytics for the actual SDK.

What is the need for RudderAnalyticsPreloader?

[fxenik]

@saikumarrs any idea what this RudderAnalyticsPreloader is about?

[saikumarrs]

For CDN installations, the SDK loading snippet creates function stubs for tracking calls like track, page etc. where window.rudderanalytics just acts as a buffer for collecting all such function invocations until the SDK loads.
Once the SDK is loaded, it'll process all these buffered calls.

RudderAnalyticsPreloader represents the type of window.rudderanalytics when the SDK is not loaded yet.

[fxenik]

Maybe we stick to the Kotlin convention, where we start with the event type, followed by the event name in case of tracks. e.g:

identify(...)
trackSomeTrackEvent(...)

[fxenik]

For event rule types, let's also stick to the same convention as in Kotin. Interfaces start with the event type, followed by name in case of tracks, then followed by the identity section of that rule e.g:

IdentifyProperties
TrackSomeTrackEventProperties

[fxenik]

As a general guideline, for every property let's generate an interface or type for each property. e.g:

type PropertySomeString = string;

Then use that type in every place (rule of custom type) that property is used, e.g:

interface TrackSomeTrackEventProperties {
  someString?: PropertySomeString;
}

[fxenik]

Specifically for enums, in order to avoid to S_ and N_ prefixes, can we considering listing the exact values in the type, e.g:

type Foo = 'GET' | 'POST' | '200' | 200;

[fxenik]

Let's skip the wrapping CustomTypeDefs interface, as it doesn't represent any actual type. Let's instead generate interfaces (or types) with a CustomType prefix, e.g:

type CustomTypeSomeStringType = string;

the property using that would look like:

type PropertyCustomString = CustomTypeSomeStringType;

[fxenik]

Again, following Kotlin conventions, let's create a single type for objects with nested properties, e.g:

interface TrackSomeTrackEventProperties { // this is the type for the entire event rule
...
  someNestedObject: {
    someNestedLevel1?: {
      someNestedLevel2?: {
        someString?: string;
        someInteger?: number;
      }
    }
  }
...
}

This avoids name conflicts for any nested object, without overly complicated interface names. It also makes the type definition local to the event rule type definition, which is what is expected.

[fxenik]

I don't have a good suggestion out of the box, but it would be nice to see if we can define a type for the discriminator in the default case, where it accepts everything but the values defined in the cases.