Customize location of JavascriptInitializer javascript

[POnakS]

Is there an existing issue for this?

• [X] I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

App automatically downloads javascript initializers from _content/*/*.lib.module.js, in example _content/Microsoft.AspNetCore.Components.CustomElements/Microsoft.AspNetCore.Components.CustomElements.lib.module.js. This behavior is well documented here. Path of this initializer is automatically prefixed by document.baseURI.

My app is part of bigger app created in microfrontend fashion and I need to load my scripts from /my-product path. App base path is default ('/'), and I cannot change it, as it would affect all products. Blazor attempts to load all files from _content/*/*.lib.module.js, however it should load them from /my-product/_content//.lib.module.js`, as I am unable to host it in root directory.

Describe the solution you'd like

Ability to customize location of initializers, i.e. configure prefix which will be applied to all initializers instead of document.baseURI, or function similar to loadBootResource which can be passed to Blazor.start.

Additional context

May be related to https://github.com/dotnet/aspnetcore/issues/38690, however I cannot set base path

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[jdevillard]

Same issue for me but I want to be able to load my Blazor WASM from a remote location. loadBootResource works well for all manifest/assembly/pdb etc... but this CustomElements module (and maybe other ) are indeed loaded from document.baseURI and the inability to load this module broke the loading of all the application.

 async importInitializersAsync(e, t) {
            await Promise.all(e.map((e=>async function(e, n) {
                const r = function(e) {
                    const t = document.baseURI;
                    return t.endsWith("/") ? `${t}${e}` : `${t}/${e}`
                }(n)
                  , o = await import(r);
                if (void 0 === o)
                    return;
                const {beforeStart: s, afterStarted: a} = o;
                return a && e.afterStartedCallbacks.push(a),
                s ? s(...t) : void 0
            }(this, e))))
        }

[max-meng1]

Blazor app too much relies on document.baseURI, it makes CustomElements harder to use, as embeded Blazor app won't always share same root path as its host website

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[POnakS]

Something is wrong with the BOT :/

[CoskunSunali]

We see symptoms from the same issue, but our use case is multi-tenancy. We would like different authorization policies surrounding anything being served from within our application, so we have our routes defines as {tenantKey}/sub/path and we also have a <base href="/exampleTenantKey/" /> tag in the header.

No matter how much I tried, none of the workarounds I was able to come up with feel suitable for production environments. I even tried rewriting the response body for initializers endpoint which serves paths to the initializers in an array. I prepended the paths with / to make them relative to the root directory, but I ended up with request paths such as /exampleTenantKey//lib-name/lib-name.lib.module.js instead of /lib-name/lib-name.lib.module.js which is not desired - please beware of the double slashes.

If only the function mentioned in https://github.com/dotnet/aspnetcore/issues/48949#issuecomment-1719163206 checked whether path parameter started with a / and immediately returned, at least the "rewrite response body" workaround would work.

    function adjustPath(path: string): string {
      if (path.startsWith('/')) {
        return path;
      }

      // This is the same we do in JS interop with the import callback
      const base = document.baseURI;
      path = base.endsWith('/') ? `${base}${path}` : `${base}/${path}`;
      return path;
    }

Can you suggest a viable workaround for this scenario?

// CC @javiercn because looks like you implemented this logic and maybe kindly can provide us with a workaround?