Discussions
Categories
- 196.7K All Categories
- 2.2K Data
- 235 Big Data Appliance
- 1.9K Data Science
- 449.9K Databases
- 221.6K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 549 MySQL Community Space
- 478 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3K ORDS, SODA & JSON in the Database
- 532 SQLcl
- 4K SQL Developer Data Modeler
- 186.9K SQL & PL/SQL
- 21.3K SQL Developer
- 295.4K Development
- 17 Developer Projects
- 138 Programming Languages
- 292.1K Development Tools
- 104 DevOps
- 3.1K QA/Testing
- 645.9K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 153 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.1K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 17 Java Essentials
- 158 Java 8 Questions
- 85.9K Java Programming
- 79 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.2K Java SE
- 13.8K Java Security
- 203 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 398 LiveLabs
- 37 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.6K Other Languages
- 2.3K Chinese
- 170 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 230 Portuguese
pack to pack linking

I have a common pack hrt-osc that holds a library in common that does the linking and security to our service cloud instance. I also have two other packs hrt-accomm and hrt-cat-erm that need to call the service cloud but have its own functionality. I have just started this work in Typescript 12.1.0. When I add the library to the viewModel of a page it works, but if I try to add it to the other components within the packs, it does not work
The Weird thing is that within Visual Studio Code, the import appears to work and it also has a handle to the methods within, so that I can use type ahead, but when compiling, it is looking for the common component within its own path of the exterior pack.
In the picture above, hrt-accomm has to connect to service cloud through hrt-osc/common/libs/. The Code below works in the the viewModel of a page, but does not work in the hrt-accomm web components. I'm sure it is a dependency that I need to add, but can not find out where for the TypeScript Application. I started the application with "ojet create ojet-core --template=navbar –typescript"
import {Connection} from "hrt-osc/common/libs/libraries";
....
Connection.localMakeRequest("/cc/data/getAppVars").then((response)=>{
console.log(">>delegate-list::init::getappvars", response);
}).catch((ex) =>{
console.error(">>delegate-list::init::getappvars", ex);
})
Best Answer
-
I'm pretty sure that the work around for this will be to ensure that the optimizer does not try and cross bundle the packs when processing each component. We can do that by setting the correct paths to "empty:" in the before_component_optimize hook, it would just need a little logic to work out the correct ones to set as each component is processed.
A basic hook impl to set or override the path correctly might look a little like this: (/scripts/hooks/before_component_optimize.js)
const path = require('path'); 'use strict'; module.exports = function (configObj) { return new Promise((resolve, reject) => { console.log("Running before_component_optimize hook."); //Set the hrt-osc path to empty for any of the other pack components //so they don't try and cross-bundle the code during optimization if (!configObj.componentRequireJs.name.startsWith('hrt-osc/')){ configObj.componentRequireJs.paths['hrt-osc'] = 'empty:'; } resolve(configObj); }); };
Answers
-
I have done further research on this. I have followed Create Resource Components for JET Packs and my structure for "hrt-osc" is slightly different.
When I "ojet build --release" and have reference and use the common-libraries in a view viewModel.js, the application compiles without error. When I have reference and use it within a web component in another pack, then I get the following exception:
no such file or directory, open 'C:/ClientWork/Azure/ojet-core/web/js/jet-composites/hrt-accomm/1.0.0/hrt-osc/common-libraries/index.js'
It appears to be looking for the common-libraries within its own directory structure instead of the the proper one.
I then thought that maybe it requires an entry within "component.json" of the child pack, so I added ","hrt-osc-common-libraries":"1.0.0"" within the dependencies section, following "Consume the Reference Component", but then when building I get the following error:
Error: Missing pack prefix for component hrt-osc-common-libraries in hrt-accomm
The strange thing is that there is no issue when coding within Visual Studio Code. The references all work and I can use the package both in my view viewModel and also my component viewModel.
-
Nathan, your code is correct in that the references to the shared code from the other packs should be based on the path 'hrt-osc/common/libs/libraries'
What version of the ojet cli are you running with here?
-
I'm pretty sure that the work around for this will be to ensure that the optimizer does not try and cross bundle the packs when processing each component. We can do that by setting the correct paths to "empty:" in the before_component_optimize hook, it would just need a little logic to work out the correct ones to set as each component is processed.
A basic hook impl to set or override the path correctly might look a little like this: (/scripts/hooks/before_component_optimize.js)
const path = require('path'); 'use strict'; module.exports = function (configObj) { return new Promise((resolve, reject) => { console.log("Running before_component_optimize hook."); //Set the hrt-osc path to empty for any of the other pack components //so they don't try and cross-bundle the code during optimization if (!configObj.componentRequireJs.name.startsWith('hrt-osc/')){ configObj.componentRequireJs.paths['hrt-osc'] = 'empty:'; } resolve(configObj); }); };
-
Ferris Bueller.. Your my hero...