feat: enable appium-inspector as an appium plugin

[KazuCocoa]

Complete partially in appium/appium#20834

Final PR instead of #1868, which was ordinally just for a prototype.

After this PR merge, we should run npm publish as README's release section in this PR if needed for now. I'll also create a follow-up PR to make it automated as part of the existing workflow https://github.com/appium/appium-inspector/blob/main/.github/workflows/package.yml to push the npm package as well.

• make this inspector's web-based contents via /inspector endpoint
• available via npm
  • @appium/inspector-plugin or appium-inspector-plugin, which is better naming...? <- this will be in the follow-up PR
    • https://www.npmjs.com/package/appium-inspector-plugin is the current prototype place by @saikrishna321

[mykola-mokhnach]

should it be a part of the common build script?

[KazuCocoa]

I'd like to include this in build after completing npm publish work as well, so yes but not yet in this PR.

[mykola-mokhnach]

same as above

[mykola-mokhnach]

same as above

[mykola-mokhnach]

I would say this script should be executed automatically as soon as we bump the version of the main project via npm version

[KazuCocoa]

Yes. It will be a follow-up PR to treat npm publish stuff in my current plan.

[KazuCocoa]

Local version: seems to open, but unfortunately it does not load the English translations, which means that many places use the raw translation keys, making it difficult to navigate.

How could I check it?
e.g. on my local with the Development steps:

@eglitise

(npm install is out of scope for now as I haven't tested it well yet. We may need to push with latest, and potentially need to do more)

[eglitise]

How could I check it?

When I activate the plugin and open the inspector page, Appium logs all the HTTP requests, which is where I am observing the 404 response:

[HTTP] --> GET /inspector {}
[HTTP] <-- GET /inspector 200 18 ms - 334
[HTTP] --> GET /inspector/assets/index-CNB9fSg_.css {}
[HTTP] --> GET /inspector/assets/index-B5YrvsL3.js {}
[HTTP] <-- GET /inspector/assets/index-CNB9fSg_.css 200 10 ms - 691539
[HTTP] <-- GET /inspector/assets/index-B5YrvsL3.js 200 2 ms - 6732856
[HTTP] --> GET /locales/en/translation.json {}
[HTTP] No route found for /locales/en/translation.json
[HTTP] <-- GET /locales/en/translation.json 404 5 ms - 211

[KazuCocoa]

I see. Then, maybe somewhere may have hard code to /locales where is not modified with --base option in vite.

appium-inspector/app/web/polyfills.js

Lines 5 to 8 in d4c6099

	const localesPath =
	process.env.NODE_ENV === 'development'
	? '/locales' // 'public' folder contents are served at '/'
	: '../locales'; // from 'dist-browser/assets/'

?

[eglitise]

It is confusing that the locales load fine for you, though 🤔 maybe the translations are cached? If I open a new private window/incognito, the cache is cleared and I get the 404 again.

[eglitise]

This seems to do the trick and works correctly in both web and plugin builds:

// Adjust locales path depending on Vite base (web vs plugin)
const viteBase = import.meta.env.BASE_URL;
const vitePath = viteBase.endsWith('/') ? viteBase : `${viteBase}/`;

const localesPath =
  process.env.NODE_ENV === 'development'
    ? '/locales' // 'public' folder contents are served at '/'
    : `..${vitePath}locales`; // from 'dist-browser/assets/'

[KazuCocoa]

Yea, my env could be the browser cache reason.