DavidWells / DavidWells/analytics
all: false always disables all plugins
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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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