Can you import the HttpService and use it instead of axios? Something like this:

  const httpServiceSetupMock = new HttpService().setup({
    injectedMetadata: injectedMetadataServiceMock.createSetupContract(),
    fatalErrors: fatalErrorsServiceMock.createSetupContract(),
  });

  httpService.setup(httpServiceSetupMock);

Thanks for the suggestion. I ended up trying with

// httpServiceMock.createSetupContract() returns an HttpSetupMock from core
httpService.setup(httpServiceMock.createSetupContract());

but this breaks our tests. Probably because our sinon.fakeServer() requires a real http client like axios`. Will need to be investigated and changed in all our apps later.

FWIW I did get this working for remote_clusters (PR: #57365). I did have to adjust the timeouts though.

Cool. Did you try by providing directly the httpServiceMock.createSetupContract()) from core?

The tests seem to be passing for me now locally.

nit: all core mocks should be available via src/core/public/mocks

should this be notificationServiceMock.createSetupContract()?

They are both the same, but for consistency let's use the createSetupContract () 👍

Why did UIM_EDIT_CLICK get moved to common? If these constants aren't being consumed by both public and server code, then I think they belong in public.

This is probably from the merge conflict resolution. There are no UIM_EDIT_CLICK in the common folder so importing it is probably undefined.. Will revert that change. 👍

When do you plan to address this TODO?

I'm happy to see this note here because it did surprise me to see this function available from this module. When do you plan to address this TODO?

Nit: Personally I find grouping imports by how distant they are from the file makes it easier to reason about relationships between the imports and the file importing them. For example, I know ShowJson, Summary, and EditSettingsJson are local to this file so I expect to be able to refactor them more easily because they probably aren't meant for external consumptions. So I'd put this import on line 32.

I also like that structure of ordering importing and I've already updated the imports order whenever I bump into them. I've seen in places in our code absolute path coming after relative ones.

What is the benefit of using the name setup in these services? I'm finding it confusing because one core aspect of the NP mental model is that of the lifecycle, defined by setup, start, and stop. These terms are associated with plugins and how they work, but as far as I can tell these services have no knowledge of the plugin lifecycle. Is there an instance in which we'd need to start or stop a service?

If not, then I think we should avoid using lifecycle terms. This will avoid overloading them, allowing us to grep for calls to setup( with confidence that any hits will be related to the NP lifecycle.

So this change is to align on terms and simplify the mental model. Those setup function are meant to be called.... at plugin setup() lifecycle time. And this method does that: set up the service, passing down any required dependencies to the service.

We could call it: "init", "register", "setup", " it does not really matter. But I like to have 1 standard and stick to it.

These terms are associated with plugins and how they work

If you look at core services, like HttpService, you will see it is not only plugins but also services that align on the setup, start and stop public method.

Is there an instance in which we'd need to start or stop a service?

Well, your question made me see that we might have a memory leak with the current License.ts implementation.

// this is the logic inside its setup() function
licensing.license$.subscribe(license => {
  const { state, message } = license.check(pluginId, minimumLicenseType);
  const hasRequiredLicense = state === LICENSE_CHECK_STATE.Valid;

  if (hasRequiredLicense) {
    this.licenseStatus = { isValid: true };
  } else {
    this.licenseStatus = {
      isValid: false,
      message: message || defaultErrorMessage,
    };
    if (message) {
      logger.info(message);
    }
  }
});

We might have to unsubscribe when the plugin is stopped (and call the stop() method on this service. I will check

Does this application use a router? If so it needs to be configured with appBasePath to ensure it works with the basePath correctly. Once #56705 is merged, you will need to use the history instance that is provided with your react-router.

Setting the basename on the react router does not work as we already add the base path manually on each route like so

<Switch>
  <Route exact path={`${BASE_PATH}create_template`} component={TemplateCreate} />
  <Route exact path={`${BASE_PATH}clone_template/:name*`} component={TemplateClone} />
  <Route exact path={`${BASE_PATH}edit_template/:name*`} component={TemplateEdit} />
  <Route path={`${BASE_PATH}:section(indices|templates)`} component={IndexManagementHome} />
  <Redirect from={`${BASE_PATH}`} to={`${BASE_PATH}indices`} />
</Switch>

Do you recommend to refactor and use the basename prop on the router?