Expose helpers as shared module and usable while writing custom code

[alcazes]

I am working on a private extension at the moment and I noticed that the core extension already provides specific helpers methods that I would like to reuse as sharedModules and as helpers when I wrote custom code in rule and data elements.

I am interested in the following helpers:

• getObjectProperty https://github.com/adobe/reactor-extension-core/blob/master/src/lib/helpers/getObjectProperty.js
• textMatch https://github.com/adobe/reactor-extension-core/blob/master/src/lib/helpers/textMatch.js
• valueComparison https://github.com/adobe/reactor-extension-core/blob/master/src/lib/conditions/valueComparison.js
• variable https://github.com/adobe/reactor-extension-core/blob/master/src/lib/conditions/variable.js

I am aware that variables and valueComparison are both linked to specific conditions but it would be ideal to move them to helpers.

Ideally once exposed the use will be:

• when writing private extensions use turbine.getSharedModule('core', 'getObjectProperty'); to reuse in code to avoid writing similar code for same purpose
• in configuration add an option to expose helpers to window._satellite.helpers.getObjectProperty to reuse in custom code section in Adobe Launch rules and data elements

[alcazes]

At the moment I copied the helpers inside my private extension build, this leads to redundant code that is why I would like to use sharedModules capabilities and expose to window

[Aaronius]

Thanks @alcazes! I understand your desire to have these as shared modules. There are some downsides to having them as shared modules at the moment that we'll need to take into consideration. If the code were exposed as a shared module, it will always be included in all Launch libraries for all Launch properties that have Core installed, regardless of whether the code is used in the library or not. This is because the system that builds the Launch library isn't smart enough to know if another extension in the library is actually using the shared module (e.g., makes a call to turbine.getSharedModule('core', 'getObjectProperty');), so it always includes the shared module code just in case. On the other hand, if the code is not exposed as a shared module, it can be trimmed based on the features of the Core extension that a particular library might be using (see https://medium.com/adobetech/build-optimization-through-minimal-inclusion-87ea637e174f for more info).

We want to eventually improve the build process in such a way that we could determine whether a shared module is actually being used by another extension in the same library and, if not, exclude the shared module code from the library builds. Until then, I think this issue will need to stay open because the cost to everyone's library size would be too great for the potential benefit received.

[thebenrob]

@adobe export issue to Jira project PDCL

[github-jira-sync-bot]

✅ Jira issue PDCL-6236 is successfully created for this GitHub issue.

[alcazes]

Checking in to make sure this request has not been forgotten.

Some of our platform have raised that Adobe launch seems to be one of the biggest library to load initially so at the moment every kb counts.

[mems]

I would like to add load-script to the list of shared module usable in custom code.
I.E. something could look like _satellite.loadScript(), like we have _satellite.cookie.set() for cookies.

[alcazes]

I would like to add load-script to the list of shared module usable in custom code. I.E. something could look like _satellite.loadScript(), like we have _satellite.cookie.set() for cookies.

At present I was able to achieve this using a private extension:

But it would be great if it was available out of the box.