Enable HMR when not running on localhost?

[Altneuj]

We are proxying the bundles/emulator served by pilet debug command onto our webapp (shell) that is not running on localhost. Not running on localhost is needed for many reasons, one being to avoid CORS issues with our APIs. This works well except for HMR breaking due to the assumption that this will be the same origin as our pilet https://github.com/smapiot/piral/blob/d1a8b8ff89b879002aaf5ec91e0aa5772393162c/src/tooling/piral-cli/src/injectors/pilet-injector.ts#L93

headers.origin will resolve to our webapp url instead of localhost:4321 (for example)

it is possible to instead derive this baseUrl from the 'dbg:pilet-api' to make sure we hit the correct pilet get route or is there something I am potentially missing?

Thank you!

[FlorianRappl]

To avoid CORS issues with your APIs you can use the mock server. That's why the Piral CLI starts a kras server - such that you can easily proxy and manipulate such requests / responses.

Also the Piral Inspector (browser extension) is written to be only active for localhost pages, so being on a non-localhost address would also exclude this.

However, if you still would like to use a non-localhost address then I guess we'd need either to change that computation (use, e.g., the original address of the dev server) or introduce a config option.

I think going with a config option (via the .krasrc) seems like the best way forward to me.

[Altneuj]

Yeah I have tried the mock server and it is very helpful with some of this (the har injection is really cool stuff especially) but being able to run on non localhost is just a bit easier as we can sidestep issues with auth and mapping of subdomains in our hosts etc..

I have also run into that issue with the piral-inspector and for now have been calling the debug commands via postMessage in my shell. Though an option to add more domain matches for the extension would be ideal, but to be fair I don't know the full implications that go along with doing that. I just know it seems to just work when changing the matches params locally and running the extension.

I would be happy to write and submit the changes to optionally consume a config option from krasrc at that baseURL if you could just tell me a little more what you think a good name/description for the config option. I could see some sort of debugServer option 🤷 but it would probably be duplicating some of the values we may already have in the krasrc like host port etc.. (but then again I guess those values can be different than the dev server no?

Thanks for such a quick response!

[FlorianRappl]

Yeah we thought about the URL restriction, however, not restricting it would mean that the extension essentially starts for every website. This is something that I find personally, as a user, too obtrusive. It's unfortunate that this setting cannot be changed / handed over into the hands of the end-user (i.e., make the URL restriction just a starting value, but leave the exact behavior / URLs up to the end-user). Maybe this is possible, but I do not know enough of the extension manifest here.

Regarding the name of the config ... naming is hard, so I'd guess something like assetBaseUrl could be a good name (open for discussion / change here).

This would be a config for the pilet injector, e.g., it would look like

{
  "injectors": {
    "pilet": {
      "assetBaseUrl": "http://custom-domain.com/pilet"
    }
  }
}

[Altneuj]

yeah I was looking into the same with the manifest and there doesn't seem to be a great option currently for defaulting to a URL and then allowing others. Maybe I will poke around at it eventually.

I am going to go ahead and write up a PR for the config change. Thanks very much!

[FlorianRappl]

This is now in and called assetUrl:

{
  "injectors": {
    "pilet": {
      "assetUrl": "http://custom-domain.com/pilet"
    }
  }
}

It also goes beyond the WebSocket and transforms the meta response, too.