Kevin Jump
04/23/2024, 12:08 PMKevin Jump
04/23/2024, 1:01 PMts
const detailsModal = this.#modalManagerContext?.open(this, USYNC_DETAILS_MODAL, {
data: {
item: action,
},
});
All stadard and all 'working' at a typescript level.
problem comes from how the package(s) are bundled i think.
because in Umbraco we get :
index.js:27 Uncaught (in promise) DOMException: Failed to execute 'define' on 'CustomElementRegistry': the name "usync-details-modal" has already been used with this registry
at https://localhost:44302/umbraco/backoffice/c5264d27ed374c283a729f998d59bceda50d8626/external/lit/index.js:27:101
at _ (https://localhost:44302/App_Plugins/uSync/details-modal-element-CIinhEQ3.js:5:42)
at https://localhost:44302/App_Plugins/uSync/details-modal-element-CIinhEQ3.js:44:5
I think that is because with VITE building the uSync.Complete package it will include the elements of the uSync package we have used.
and that means things are being defined twice in umbraco
If i tell vite to treat the usync package as an external resource in the vite.config :
ts
external: [/^@umbraco/, /^@jumoo\/usync-assets/],
then i get a diffrent error in the browser .. because it doesn't know how to import @jumoo/usync-assets
entry-point-extension-initializer.js:41 Uncaught (in promise) TypeError: Failed to resolve module specifier "@jumoo/usync-assets/dialogs". Relative references must start with either "/", "./", or "../"
Kevin Jump
04/23/2024, 1:20 PMKevin Jump
04/23/2024, 2:29 PM@jumoo/usync-assets
imports to folders e.g
json
"importmap": {
"imports": {
"@jumoo/usync-assets/dialogs": "/App_Plugins/uSync/lib/dialogs/index.js"
}
}
this probibly means i don't want vite to do anything clever with my build?
because i want the library to be predictable ? so the other packages can look it up ?
is this the right way to be heading ?Kevin Jump
04/23/2024, 4:27 PMts
rollupOptions: {
external: [/^@umbraco/],
output: {
manualChunks: (f) => {
if (f.indexOf('src') > 0) {
let path = f.substring(f.indexOf('src') + 4);
path = path.substring(0, path.length - 3);
console.log(path);
return path;
}
},
chunkFileNames: '[name].js',
},
onwarn: () => {},
},
Kevin Jump
04/23/2024, 4:27 PMKevin Jump
04/23/2024, 4:28 PMKevin Jump
04/23/2024, 5:28 PMnathanwoulfe
04/23/2024, 9:19 PMJason
04/29/2024, 11:57 PM@umbraco-cms
"package" does.
Umbraco itself gets built with a single dependency graph that can be nicely managed by Vite and NPM. Packages, on ther other hand, are built separately, and as soon as you need to share code between packages, a lot of the niceness of dependency management with Vite and NPM goes away.
I think using the "external" approach with your consuming package, and an import map in your lib package is the best approach - what you need will already have been provided/registered by the other package (assuming uSync.Complete depends on it via NuGet) - then this works the same way as the @umbraco-cms
stuff.
You don't need paths to be predictable - the point of the map is that your library package itself registers an alias for where @jumoo/whatever
lives, so your consuming packages can just import @jumoo/whatever
and it'll get mapped to the correct file. I'd let Vite do its thing (it works fine for the @umbraco-cms
packages).Kevin Jump
04/30/2024, 7:21 AM@Umbraco-cms
package does it. (which is a bit different that the page thing in that it does preserve the library paths much more (its closer to just a tsc build
)
the issue where i got a bit stuck, and had to park it just for now was external dependencies within the package you then want to share, (in my case signalR). because if you build it like the core umbraco package these are not merged into your final code.
if you look at how the core does this it builds and minifies the the external packages in the /external folder of the library, and then references them from there. and i sort of got that going, but to be honest there are now only 20 working days until may 30th, so i moved on to some functionality building stuff!Jason
04/30/2024, 7:58 AMimport { browserNotificationService } from "base-package";
Kevin Jump
04/30/2024, 8:07 AMKevin Jump
04/30/2024, 8:32 AMJason
04/30/2024, 9:12 AM