DavidWells / DavidWells/analytics

all: false always disables all plugins

Open
#455 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
2.7k
Forks
267
PR merge metrics
No merged PRs in 30d

Description

As per the docs you can send events to a single destination with the following properties when sending the event:

analytics.track('eventName', additionEventProps, {
  plugins: {
    // disable this specific track call for all plugins except customerio
    all: false,
    customerio: true
  }
})

This would disable all plugins except customerio and therefore the data would be sent onto to customerio.

A common use case for plugins is to enrich data or do something else that is not related to sending data to a provider (e.g. filtering events).

However, the use of all: false also disables any enricher-only plugins you might be using meaning that you need to have event configuration like:

analytics.track('eventName', additionEventProps, {
  plugins: {
    // disable this specific track call for all plugins except customerio
    all: false,
    customEnricher: true,
    customerio: true
  }
})

This can be quite error-prone as its not immediately obvious that all: false will have side effects of turning off enrichers and means that developers need to always be mindful of re-enabling any custom plugins following an all: false.

It would be great if there was an option for a plugin to be able to ignore the all: false flag and always be enabled in this scenario.

Something like:

export default function customEnricherPlugin(userConfig) {
  return {
    name: 'custom-enricher',
    alwaysEnabled: true, // <- something like this or ignoreAll: true
    config: {
      whatEver: userConfig.whatEver,
      elseYouNeed: userConfig.elseYouNeed
    },
    initialize: ({ config }) => {
      // ...
    },
    track: ({ payload }) => {
      // ...
    },
    ...
  }
}

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files or tests are named. Start by tracing how per-call plugin configuration handles the all flag and plugin definitions, then determine how an always-enabled enricher should interact with provider selection. Done means an opt-in plugin can remain enabled when all: false is used, while the documented customerio-only behavior still works.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.