Migration Guide: From @elbwalker to @walkerOS
This guide helps you migrate from the old elbwalker packages to the new walkerOS packages.
Quick Reference
Core Package Changes
@elbwalker/walker.js→@walkeros/collector+@walkeros/web-source-browser@elbwalker/types+@elbwalker/utils→@walkeros/core@elbwalker/destination-web-*→@walkeros/web-destination-*@elbwalker/destination-node-*→@walkeros/server-destination-*
Step-by-Step Migration
1. Update Dependencies
Before:
After:
2. Update Imports
Before:
After:
3. Update Function Calls
Before:
After:
Breaking Changes
1. Unified Collector
- Single
@walkeros/collectorpackage works across all platforms - Use
startFlow()instead ofWalkerjs()orcreateSourceNode()
2. Modular Sources
- DOM tracking is now
@walkeros/web-source-browser - Import and initialize sources separately
3. Core Package Merger
- All types and utilities now come from
@walkeros/core - Update all import statements accordingly
4. Google Destinations Unified
- GA4, Google Ads, and GTM are now unified in
@walkeros/web-destination-gtag - Configure all Google services through a single destination
Destination Configuration Patterns
Unified Configuration Approach
Configure all sources and destinations in a single startFlow call:
Benefits:
- Single configuration describing entire tracking setup
- Full type safety with proper config linking
- No manual destination registration needed
- Clean separation between code and configuration
Migration Checklist
Package Dependencies
- [ ] Remove old
@elbwalker/*packages - [ ] Add
@walkeros/collector - [ ] Add required sources and destinations
- [ ] Add
@walkeros/corefor custom implementations
Code Updates
- [ ] Update all imports to new packages
- [ ] Replace collector initialization with
startFlow() - [ ] Update type imports to use
@walkeros/core - [ ] Test functionality after migration
Common Issues
"Cannot find module @walkeros/web-collector"
Solution: Use @walkeros/collector + @walkeros/web-source-browser
"elb is not defined"
Solution: elb is returned by startFlow() function
TypeScript cannot find types
Solution: Import types from @walkeros/core
data-elbaction vs data-elbactions
Breaking Change in @walkeros packages
The behavior of data-elbaction has changed to improve performance and provide
more precise entity targeting:
- @elbwalker behavior:
data-elbactionapplied to all entities in the DOM hierarchy - @walkeros behavior:
data-elbactionapplies to nearest entity only
Migration Strategy
Option 1: Keep Current Behavior (Recommended for migration)
Replace data-elbaction with data-elbactions to maintain the same behavior:
Option 2: Use New Behavior (Recommended for new projects)
Use data-elbaction for more precise, performance-optimized tracking:
When to Use Each
Use data-elbaction (nearest entity) when:
- You want precise tracking of only the specific entity
- Performance is critical (fewer events)
- Implementing new features
Use data-elbactions (all entities) when:
- Migrating from @elbwalker and need same behavior
- You need context from parent entities
- Analytics requires full DOM hierarchy
Tagger API
The tagger also provides both methods:
visible vs impression Triggers
Breaking Change in @walkeros packages
The visibility trigger names have been updated to better reflect their behavior:
visibletrigger: Now fires multiple times when element re-enters viewport (wasvisibles)impressiontrigger: Fires once only when element first becomes visible (wasvisible)
Migration Strategy
Option 1: Update Trigger Names (Recommended)
Update your HTML to use the new trigger names:
Option 2: Understand the Behavior Change
If you keep using the old names, understand the behavior has changed:
- Old
visiblebehavior (single-fire) → Now useimpression - Old
visiblesbehavior (multiple-fire) → Now usevisible
When to Use Each
Use impression trigger when:
- You want to track when content is first seen
- Measuring ad impressions or content views
- One-time engagement metrics
Use visible trigger when:
- You want to track repeated interactions
- Measuring scroll behavior or re-engagement
- Analytics requires multiple visibility events
Tagger API
The tagger supports both trigger types: