datalayerjs - npm Package Compare versions

Comparing version 0.0.3 to 0.0.4

package.json

 {
   "name": "datalayerjs",
-  "version": "0.0.3",
+  "version": "0.0.4",
   "description": "An open-source datalayer, tagmanager and frontend middleware",
-  "main": "dist/datalayer.cjs.js",
-  "module": "dist/datalayer.esm.js",
+  "author": "Rico Pfaus",
+  "license": "MIT",
+  "homepage": "https://github.com/ryx/datalayerjs",
+  "keywords": [
+    "tagmanager",
+    "datalayer",
+    "affiliate",
+    "attribution"
+  ],
+  "main": "dist/datalayer.umd.js",
+  "module": "src/index.js",
   "scripts": {
@@ -11,7 +20,6 @@ "test:spec": "jest --coverage",
     "test": "npm run test:lint && npm run test:spec",
-    "build:cjs": "rollup src/datalayer.js --o dist/datalayer.cjs.js -f cjs",
-    "build:esm": "rollup src/datalayer.js --o dist/datalayer.esm.js -f es",
-    "build:umd": "rollup src/datalayer.js --o dist/datalayer.umd.js -f umd --name \"datalayerjs\"",
-    "build": "npm run build:cjs && npm run build:esm && npm run build:umd",
-    "dev": "DTLR_DEBUG=1 babel-node test/plugin.js"
+    "build:umd": "webpack --mode=development",
+    "build": "npm run build:umd",
+    "dev": "DTLR_DEBUG=1 babel-node test/plugin.js",
+    "prebublish": "npm run build"
   },
@@ -22,13 +30,5 @@ "repository": {
   },
-  "keywords": [
-    "tagmanager",
-    "datalayer",
-    "affiliate",
-    "attribution"
-  ],
-  "author": "Rico Pfaus",
-  "license": "MIT",
-  "homepage": "https://github.com/ryx/datalayerjs",
   "devDependencies": {
     "babel-eslint": "^8.0.1",
+    "babel-loader": "^7.1.4",
     "babel-plugin-dynamic-import-node": "^1.1.0",
@@ -46,4 +46,4 @@ "babel-plugin-external-helpers": "^6.22.0",
     "jsdom": "^11.3.0",
-    "rollup": "^0.50.0",
-    "rollup-plugin-babel": "^3.0.2"
+    "webpack": "^4.6.0",
+    "webpack-cli": "^2.0.14"
   },
@@ -50,0 +50,0 @@ "dependencies": {

README.md

@@ -6,9 +6,9 @@ # datalayer.js
 
-Datalayer.js is a datalayer, tagmanager, and *"frontend middleware"*. It follows a "developer first" philosophy, is open-source and fully test-driven. It acts as a data proxy between the client and any third parties, which are embedded by plugins. Datalayer.js is based on a [customizable data model with a virtual type system](#models) and aimed at standardizing and simplifying the process of 3rd party integration into today's websites.
+Datalayer.js is an open-source datalayer, tagmanager, and *"frontend middleware"*. It is based on a [customizable data model with a virtual type system](#models) and aims at standardizing and simplifying the process of 3rd party integration into modern websites. It follows a "developer first" philosophy, is fully test-driven and acts as a thin data proxy between the client and any third parties, which are provided by plugins.
 
-> NOTE: this is still a **very early version** that likely contains bugs and documentation issues :boom:
+> NOTE: this is still a **pre-release version**, we are actively working on our the first stable relase .. :boom:
 
 
 ## How does it work?
-The Datalayer "collects" data from the website (i.e. it gets passed from different parts of your application) and aggregates it to one data object. Then the plugin loader starts loading it's plugins based on a given rule configuration (e.g. analytics scripts on each page, conversion pixels only on order confirmation, etc. ). Plugins then receive events which contain specific data, one such event is the "page-loaded" event that passes the previously aggregated data object to the plugin. Plugins can take that data and offer it to third parties as desired. That's the big picture. (TODO: add link to details)
+The Datalayer "collects" data from the website (i.e. it gets passed from different parts of your application) and aggregates it to one data object. Then the plugin loader starts loading the plugins based on a given rule configuration. Plugins will receive events which contain specific data and can take that data and offer it to third parties as desired. One example is the "page-loaded" event that passes the previously aggregated data object to the plugin. That's the big picture. (TODO: add link to details)
 
@@ -30,3 +30,3 @@ # Usage
 
-After including the datalayer.js module you have to call the [`initialize`](#initializeoptionsobject-void) method on the global instance to perform basic setup and tell datalayer.js which plugins to load. The `plugins` option is the recommended way to load plugins. You simply pass a list of plugins to be loaded and initialize them right away, using their constructor. This should work for most common usecases. One thing to keep in mind is that this _leaves the entire decision about what data the plugin receives to the plugin itself_, as the plugins take data from your website according to their own preferences.
+After including the datalayer.js module you have to call the [`initialize`](#initializeoptionsobject-void) method on the global instance to perform basic setup and tell datalayer.js which plugins to load. The `plugins` option is the recommended way to load plugins. You simply pass a list of plugins to be loaded and initialize them right away, using their constructor. This should cover the most common usecases, for more details check out the [Plugins Documentation section](). One thing to keep in mind is that this _leaves the entire decision about what data the plugin receives to the plugin itself_, as the plugins take data from your website according to their own preferences.
 
@@ -51,3 +51,3 @@ ```javascript
 ### Extensions
-In a real application you'll likely want to use extensions since they provide more, really powerful, ways of interacting with the datalayer. One common usecase is the [metadata extension](extensions/metadata) which aggregates data from the markup and passes it to the datalayer. This can be done with:
+In a real application you'll likely want to use extensions since they provide more, really powerful, ways of interacting with the datalayer. One common usecase is the [metadata extension](src/extensions/metadata) which aggregates data from the markup and passes it to the datalayer. This can be done with:
 
@@ -62,3 +62,3 @@ ```javascript
 
-Check [the extensions folder](extensions) for additional information on available extensions.
+Check [the extensions folder](src/extensions) for additional information on available extensions.
 
@@ -73,3 +73,3 @@ ## Testmode
 # Javascript API
-Communication with datalayer.js happens through the Javascript API. The module itself contains exactly one object with the name `datalayer`. The object contains the following public methods (NOTE: with the [methodQueue extension](extensions/methodQueue) you can access all of the described public API methods via the method queue pattern):
+Communication with datalayer.js happens through the Javascript API. The module itself contains exactly one object with the name `datalayer`. The object contains the following public methods (NOTE: with the [methodQueue extension](src/extensions/methodQueue) you can access all of the described public API methods via the method queue pattern):
 
@@ -122,13 +122,13 @@ ## initialize(options:Object): void
 # Models
-What are Models? The data expected by datalayer.js is defined by a set of conventions. These are based on a simple yet flexible, [virtual type system](#types), called a _model_. Simply put, such a model just defines what data is expected on which page. A page with a type of `category` for example might expect an object of type `CategoryData` holding information about the category. Models are a fundamental part of any datalayer.js-driven website. They are the foundation for implementing and validating your data, without being mandatory from a technical perspective. They are, however, a very important cornerstone for collaboration between developers, business departments and digital analysts.
+What are Models? Models are a fundamental part of any datalayer.js-driven website. They are the foundation for implementing and validating your data, without being mandatory from a technical perspective. They are, however, a very important cornerstone for collaboration between developers, business departments and digital analysts. Simply put, such a model just defines what data is expected on which page.
 
 > A "model" in terms of datalayer.js is a single JSON document that defines at least two things: all available page types for a website and all virtual type definitions that are used by those page types. Types are defined using [Apache Avro](https://avro.apache.org/docs/current/).
 
-The model definition provides the schema that defines data and event patterns for your entire website. It ultimately defines which data ends up in your datalayer and what you can provide to third parties. Although, first and foremost, it is nothing more than a convention that guides other people (developers, analysts, marketers, product management, etc.) in understanding what data to expect (or provide) where. You can think of it as the single source of truth regarding the data provided to datalayer.js.
-
 Technically seen the model is nothing more than a big JSON object with a few different properties, as described in the next sections. You are also not limited to the available data types. Instead you are *completely free* (and even encouraged) to use your own type definitions instead of the default ones. But be warned - even if it has no real technical relevance it is maybe *the most important part of your entire datalayer structure*. If you get things wrong here, you'll miss something later. Of course you are free to extend the model at any time. But it will cause developer effort and discussion, so plan well ;) ..
 
 ## Types
-The `types` property in the model contains schema definitions of the available data types that can be used throughout the rest of the model (namely the *pages* and *events* definitions). It is using [Apache Avro](https://avro.apache.org/docs/current/) to describe types so it can be parsed and processed, e.g. to automatically validate consistency of provided data on a website (we will eventually provide a validator for that purpose). Type definitions can become quite huge JSON structures
+The data expected by datalayer.js is defined by a set of conventions. These are based on a simple yet flexible, virtual type system, called a _model_. A page with a type of `category` for example might expect an object of type `CategoryData` holding information about the category. The model definition provides the schema that defines data and event patterns for your entire website. It ultimately defines which data ends up in your datalayer and what you can provide to third parties. Although, first and foremost, it is nothing more than a convention that guides other people (developers, analysts, marketers, product management, etc.) in understanding what data to expect (or provide) where. You can think of it as the single source of truth regarding the data provided to datalayer.js.
 
+The `types` property in the model file contains schema definitions of the available data types that can be used throughout the rest of the model (namely the *pages* and *events* definitions). It is using [Apache Avro](https://avro.apache.org/docs/current/) to describe types so it can be parsed and processed, e.g. to automatically validate consistency of provided data on a website (we will eventually provide a validator for that purpose). Type definitions can become quite huge JSON structures
+
 ```json
@@ -203,4 +203,20 @@ {
 # Plugins
-Datalayer.js provides a modular architecture where logic is encapsulated in plugins. These may access the global data aggregated by the datalayer and also send and receive events.
+Datalayer.js provides a modular architecture where logic is encapsulated in plugins. Plugins provide a set of predefined lifecycle methods and can access the global data that is aggregated by the datalayer. They can also send their own events, although that is a rather uncommon case.
 
+## Loading and Configuring Plugins
+Plugins are defined by creating a new instance of their class. Most plugins are configured be passing a configuration object to their constructor on instantiation.
+
+```javascript
+const plugin = new ExamplePlugin({ key: 'value' });
+```
+
+If you want to define custom loading rules you can additionally pass an optional callback function as second argument. That way the usual `shouldReceiveEvent` mechanism is ignored. This is particularly useful for loading plugins depending on certain runtime conditions (e.g. the availability of a given marketing channel's cookie, specific URL parameters and so on).
+
+```javascript
+const plugin = new ExamplePlugin(
+  { key: 'value' },
+  (data) => data.page.type === 'checkout-completed',
+);
+```
+
 ## API
@@ -207,0 +223,0 @@ Plugins are very simple Javascript objects, providing a `handleEvent` method as only convention. In fact they don't actually need to be classes at all, you could use a simple object literal as well. However, it is strongly recommended to use classes to better separate construction logic and event handling. The following example illustrates the basic structure of a plugin.

Fixed alerts

Empty package

Supply chain risk

Package does not contain any code. It may be removed, is name squatting, or the result of a faulty package publish.

Found 1 instance in 1 package

Major refactor

Supply chain risk

Package has recently undergone a major refactor. It may be unstable or indicate significant internal changes. Use caution when updating to versions that include significant changes.

Found 1 instance in 1 package

Improved metrics

Total package byte prevSize

20904

increased by8.68%

Number of package files

5

increased by66.67%

Lines of code

45

increased byInfinity%

Number of lines in readme file

293

increased by5.78%

Number of medium supply chain risk alerts

0

decreased by-100%

Worsened metrics

Dev dependency count

16

increased by6.67%

No dependency changes