[WIP]feat: add local API Explorer

[hacksparrow]

Add local API Explorer

Checklist

• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• API Documentation in code was updated
• Documentation in /docs/site was updated
• Affected artifact templates in packages/cli were updated
• Affected example projects in examples/* were updated

[hacksparrow]

@bajtos app.static seems to be overriding the ExplorerController . Any idea what's going on? Or did I misunderstand something?

[hacksparrow]

@bajtos here is the test which catches the problem. Calling restApp.static('/html', root); after restApp.controller(DummyController); passes the test. That means, something's wrong in the order of registration /look up.

[raymondfeng]

@hacksparrow Please rebase this PR off master.

[hacksparrow]

Notes on the current state of the PR

• Apps can be configured to enable the local API Explorer by passing these two config options: enableExplorer and explorerPath. Eg:

  options.enableExplorer = true;
  options.explorerPath = '/explorer1';

• On making a GET request to the root of the API Explorer as defined in explorerPath, we intent to serve a customized index.html file. However due to a current limitation, the file is not being served as text/html. Raymond is working on this issue - https://github.com/strongloop/loopback-next/tree/honor-response-content-type.

• What do we do with the currently baked-in router for /explorer?

  • Do we remove it altogether?
  • What do we do if user set explorerPath to /explorer?

[bajtos]

Apps can be configured to enable the local API Explorer by passing these two config options: enableExplorer and explorerPath.

I would personally prefer a slightly different configuration:

• To enable local API explorer, apps have to add ExplorerComponent.
• To disable local API explorer, apps should skip registration of ExplorerComponent.
  That way we can keep ExplorerComponent simpler. However, this solution may not be feasible depending on what we do with the built-in redirect to swagger-ui.

What do we do with the currently baked-in router for /explorer?

• Do we remove it altogether?
• What do we do if user set explorerPath to /explorer?

I feel that removing this feature would be a breaking change that requires semver-major. Are we ok with publishing @loopback/[email protected] just a month after v4 was released?

IMO, a better solution is to introduce a configuration flag allowing applications to disable this built-in redirect. When the Explorer component is mounted, it can set this flag to true to ensure the built-in redirect is disabled.

[bajtos]

I opened a new PR inspired by this work, see #2014