Many overall fixes

[hansottowirtz]

If you want to use these packages, they are published to npm: @adobe-fixed-uxp/uxp-devtools-helper, @adobe-fixed-uxp/uxp-devtools-cli and @adobe-fixed-uxp/uxp-devtools-core.

Changes in this PR:

• Remove inspect-frontend
• Remove templates
• Remove webdriver
• Remove feature package
• Change to Typescript
• Use pnpm and pnpm changesets
• Fix closing server
• Add Github Actions
• Setup postinstall correctly for uxp-devtools-helper
• Make multiple devtools clients possible
• Node 20 needed

I use this branch in https://github.com/bubblydoo/uxp-toolkit
e.g. you can now run:

# Opens devtools in Chrome
pnpm --allow-build=@adobe-fixed-uxp/uxp-devtools-helper dlx @bubblydoo/uxp-cli open-devtools

or

# Starts an MCP server for Photoshop
pnpm --allow-build=@adobe-fixed-uxp/uxp-devtools-helper dlx @bubblydoo/photoshop-mcp

I already opened this PR once in 2023, but now I did it a bit more thorough (with a lot of Claude help), see #10

[jardicc]

I like that you took care of this. But I personally used Webdriver for very valuable e2e testing. But also hard to configure correctly. I think you don't count on E2E tests here anymore, right?

[hansottowirtz]

That's interesting to know! I mainly made these changes to get Vitest to work over Chrome Devtools Protocol, which is now working in https://github.com/bubblydoo/uxp-toolkit/tree/main/packages/vitest-pool-uxp.
Is there any chance you can change your webdriver code to CDP code (e.g. with Puppeteer)? Or do you have these tests published anywhere open source so I can take a look?

[jardicc]

It is right here. In the templates you are about to remove as well: packages/uxp-templates-pack/uxp-wdio-automation-template/sample-tests/specs/starterScript.js

It uses wdio... there is not to much of documentation it was difficult to figure out how it actually works. Adobe uses robot.js as dependency which also uses C++ node library that can take control over your mouse and keyboard for more complex UI tests.

[jardicc]

Otherwise, I was playing with idea to have some CDP -> DAP -> CDP adapter. So it would be possible to debug in VSCode rather than UDT. https://microsoft.github.io/debug-adapter-protocol/

[hansottowirtz]

Looking at wdio.conf.js, I think this "debuggerAddress" is also just a CDP address, so I think this should not be too hard to get to work.

In the Vitest integration I made sure debugging works, e.g. inside packages/uxp-tookit you can run UXP_INSPECT=1 pnpm run test:uxp debugger --run, it will wait for you to open the devtools link in Chrome, and then it will wait on the "debugger" statement inside the "debugger.uxp-test.ts" file.

[jardicc]

Otherwise, if you look under the hood of UDT inside it looks more or less like in this repo. They just packed it into .asar archive including source code and all node modules. Therefore size +1GB :-D

[hansottowirtz]

Yes I also noticed it, but it's not really needed to use it in my opinion and that's why I deleted it. If you run the open-devtools command I posted above, you can just use Chrome to debug the apps and use the latest Devtools version.

[hansottowirtz]

I actually got the debugger in VSCode to work with Vitest. I don't know how to automatically derive the websocketAddress from the terminal, but it works with this launch.json:

{
"version": "0.2.0",
"configurations": [
{
"name": "Attach to websocket",
"type": "node",
"request": "attach",
"websocketAddress": "ws://127.0.0.1:14002/socket/cdt/a57f319c-5e63-42cd-a308-61dac5edbb2b"
}
]
}

[jardicc]

Do you find any match with adress you need in these responses?

[hansottowirtz]

I'm not sure if they are the same but they look similar. I'm not very sure why there are all these types of urls: /socket/cdt/<uuid>, /devtools/browser/<uuid> and /devtools/page/<uuid>. /socket/browser_cdt/<uuid> and /socket/cli also exist.
Where did you get this ":9123" port from?

[jardicc]

Back in the old days of UXP you could add debug file in same directory as your manifest file and specify port number for built-in Chrome Node.js debugger that would connect via CDP. This was before UDT existed. Later somewhere around PS 2023-2024 it broke.

[hansottowirtz]

I did some more research on webdriver and it seems difficult to handle properly. It's a big protocol that is quite different from CDP, you can also maximize windows, etc. The existing package Adobe created was more of a bridge to CDP, and didn't support a lot of things and seems a bit hacky to me.
I will at least try to make a Puppeteer transport first.

[hansottowirtz]

I made a @bubblydoo/uxp-puppeteer-transport package which you can use with Puppeteer, see for example:
https://github.com/bubblydoo/uxp-toolkit/blob/main/packages/example-puppeteer-integration/src/run.ts
(it's mostly vibecoded but it works)

The difficulty is that UXP CDP does not support pages etc, so those requests are intercepted. Also Runtime.evaluate with awaitPromise is not supported, so instead we poll for the promise to be done.

[hansottowirtz]

If you want to use these packages, they are published to npm: @adobe-fixed-uxp/uxp-devtools-helper, @adobe-fixed-uxp/uxp-devtools-cli and @adobe-fixed-uxp/uxp-devtools-core.

Changes in this PR:

• Remove inspect-frontend
• Remove templates
• Remove webdriver
• Remove feature package
• Change to Typescript
• Use pnpm and pnpm changesets
• Fix closing server
• Add Github Actions
• Setup postinstall correctly for uxp-devtools-helper
• Make multiple devtools clients possible
• Node 20 needed

I use this branch in https://github.com/bubblydoo/uxp-toolkit
e.g. you can now run:

# Opens devtools in Chrome
pnpm --allow-build=@adobe-fixed-uxp/uxp-devtools-helper dlx @bubblydoo/uxp-cli open-devtools

or

# Starts an MCP server for Photoshop
pnpm --allow-build=@adobe-fixed-uxp/uxp-devtools-helper dlx @bubblydoo/photoshop-mcp

I already opened this PR once in 2023, but now I did it a bit more thorough (with a lot of Claude help), see #10

[jardicc]

I like that you took care of this. But I personally used Webdriver for very valuable e2e testing. But also hard to configure correctly. I think you don't count on E2E tests here anymore, right?

[hansottowirtz]

That's interesting to know! I mainly made these changes to get Vitest to work over Chrome Devtools Protocol, which is now working in https://github.com/bubblydoo/uxp-toolkit/tree/main/packages/vitest-pool-uxp.
Is there any chance you can change your webdriver code to CDP code (e.g. with Puppeteer)? Or do you have these tests published anywhere open source so I can take a look?

[jardicc]

It is right here. In the templates you are about to remove as well: packages/uxp-templates-pack/uxp-wdio-automation-template/sample-tests/specs/starterScript.js

It uses wdio... there is not to much of documentation it was difficult to figure out how it actually works. Adobe uses robot.js as dependency which also uses C++ node library that can take control over your mouse and keyboard for more complex UI tests.

[jardicc]

Otherwise, I was playing with idea to have some CDP -> DAP -> CDP adapter. So it would be possible to debug in VSCode rather than UDT. https://microsoft.github.io/debug-adapter-protocol/

[hansottowirtz]

Looking at wdio.conf.js, I think this "debuggerAddress" is also just a CDP address, so I think this should not be too hard to get to work.

In the Vitest integration I made sure debugging works, e.g. inside packages/uxp-tookit you can run UXP_INSPECT=1 pnpm run test:uxp debugger --run, it will wait for you to open the devtools link in Chrome, and then it will wait on the "debugger" statement inside the "debugger.uxp-test.ts" file.

[jardicc]

Otherwise, if you look under the hood of UDT inside it looks more or less like in this repo. They just packed it into .asar archive including source code and all node modules. Therefore size +1GB :-D

[hansottowirtz]

Yes I also noticed it, but it's not really needed to use it in my opinion and that's why I deleted it. If you run the open-devtools command I posted above, you can just use Chrome to debug the apps and use the latest Devtools version.

[hansottowirtz]

I actually got the debugger in VSCode to work with Vitest. I don't know how to automatically derive the websocketAddress from the terminal, but it works with this launch.json:

{
"version": "0.2.0",
"configurations": [
{
"name": "Attach to websocket",
"type": "node",
"request": "attach",
"websocketAddress": "ws://127.0.0.1:14002/socket/cdt/a57f319c-5e63-42cd-a308-61dac5edbb2b"
}
]
}

[jardicc]

Do you find any match with adress you need in these responses?

[hansottowirtz]

I'm not sure if they are the same but they look similar. I'm not very sure why there are all these types of urls: /socket/cdt/<uuid>, /devtools/browser/<uuid> and /devtools/page/<uuid>. /socket/browser_cdt/<uuid> and /socket/cli also exist.
Where did you get this ":9123" port from?

[jardicc]

Back in the old days of UXP you could add debug file in same directory as your manifest file and specify port number for built-in Chrome Node.js debugger that would connect via CDP. This was before UDT existed. Later somewhere around PS 2023-2024 it broke.

[hansottowirtz]

I did some more research on webdriver and it seems difficult to handle properly. It's a big protocol that is quite different from CDP, you can also maximize windows, etc. The existing package Adobe created was more of a bridge to CDP, and didn't support a lot of things and seems a bit hacky to me.
I will at least try to make a Puppeteer transport first.

[hansottowirtz]

I made a @bubblydoo/uxp-puppeteer-transport package which you can use with Puppeteer, see for example:
https://github.com/bubblydoo/uxp-toolkit/blob/main/packages/example-puppeteer-integration/src/run.ts
(it's mostly vibecoded but it works)

The difficulty is that UXP CDP does not support pages etc, so those requests are intercepted. Also Runtime.evaluate with awaitPromise is not supported, so instead we poll for the promise to be done.

[hansottowirtz]

If you want to use these packages, they are published to npm: @adobe-fixed-uxp/uxp-devtools-helper, @adobe-fixed-uxp/uxp-devtools-cli and @adobe-fixed-uxp/uxp-devtools-core.

Changes in this PR:

• Remove inspect-frontend
• Remove templates
• Remove webdriver
• Remove feature package
• Change to Typescript
• Use pnpm and pnpm changesets
• Fix closing server
• Add Github Actions
• Setup postinstall correctly for uxp-devtools-helper
• Make multiple devtools clients possible
• Node 20 needed

I use this branch in https://github.com/bubblydoo/uxp-toolkit
e.g. you can now run:

# Opens devtools in Chrome
pnpm --allow-build=@adobe-fixed-uxp/uxp-devtools-helper dlx @bubblydoo/uxp-cli open-devtools

or

# Starts an MCP server for Photoshop
pnpm --allow-build=@adobe-fixed-uxp/uxp-devtools-helper dlx @bubblydoo/photoshop-mcp

I already opened this PR once in 2023, but now I did it a bit more thorough (with a lot of Claude help), see #10

[jardicc]

I like that you took care of this. But I personally used Webdriver for very valuable e2e testing. But also hard to configure correctly. I think you don't count on E2E tests here anymore, right?

[hansottowirtz]

That's interesting to know! I mainly made these changes to get Vitest to work over Chrome Devtools Protocol, which is now working in https://github.com/bubblydoo/uxp-toolkit/tree/main/packages/vitest-pool-uxp.
Is there any chance you can change your webdriver code to CDP code (e.g. with Puppeteer)? Or do you have these tests published anywhere open source so I can take a look?

[jardicc]

It is right here. In the templates you are about to remove as well: packages/uxp-templates-pack/uxp-wdio-automation-template/sample-tests/specs/starterScript.js

It uses wdio... there is not to much of documentation it was difficult to figure out how it actually works. Adobe uses robot.js as dependency which also uses C++ node library that can take control over your mouse and keyboard for more complex UI tests.

[jardicc]

Otherwise, I was playing with idea to have some CDP -> DAP -> CDP adapter. So it would be possible to debug in VSCode rather than UDT. https://microsoft.github.io/debug-adapter-protocol/

[hansottowirtz]

Looking at wdio.conf.js, I think this "debuggerAddress" is also just a CDP address, so I think this should not be too hard to get to work.

In the Vitest integration I made sure debugging works, e.g. inside packages/uxp-tookit you can run UXP_INSPECT=1 pnpm run test:uxp debugger --run, it will wait for you to open the devtools link in Chrome, and then it will wait on the "debugger" statement inside the "debugger.uxp-test.ts" file.

[jardicc]

Otherwise, if you look under the hood of UDT inside it looks more or less like in this repo. They just packed it into .asar archive including source code and all node modules. Therefore size +1GB :-D

[hansottowirtz]

Yes I also noticed it, but it's not really needed to use it in my opinion and that's why I deleted it. If you run the open-devtools command I posted above, you can just use Chrome to debug the apps and use the latest Devtools version.

[hansottowirtz]

I actually got the debugger in VSCode to work with Vitest. I don't know how to automatically derive the websocketAddress from the terminal, but it works with this launch.json:

{
"version": "0.2.0",
"configurations": [
{
"name": "Attach to websocket",
"type": "node",
"request": "attach",
"websocketAddress": "ws://127.0.0.1:14002/socket/cdt/a57f319c-5e63-42cd-a308-61dac5edbb2b"
}
]
}

[jardicc]

Do you find any match with adress you need in these responses?

[hansottowirtz]

I'm not sure if they are the same but they look similar. I'm not very sure why there are all these types of urls: /socket/cdt/<uuid>, /devtools/browser/<uuid> and /devtools/page/<uuid>. /socket/browser_cdt/<uuid> and /socket/cli also exist.
Where did you get this ":9123" port from?

[jardicc]

Back in the old days of UXP you could add debug file in same directory as your manifest file and specify port number for built-in Chrome Node.js debugger that would connect via CDP. This was before UDT existed. Later somewhere around PS 2023-2024 it broke.

[hansottowirtz]

I did some more research on webdriver and it seems difficult to handle properly. It's a big protocol that is quite different from CDP, you can also maximize windows, etc. The existing package Adobe created was more of a bridge to CDP, and didn't support a lot of things and seems a bit hacky to me.
I will at least try to make a Puppeteer transport first.

[hansottowirtz]

I made a @bubblydoo/uxp-puppeteer-transport package which you can use with Puppeteer, see for example:
https://github.com/bubblydoo/uxp-toolkit/blob/main/packages/example-puppeteer-integration/src/run.ts
(it's mostly vibecoded but it works)

The difficulty is that UXP CDP does not support pages etc, so those requests are intercepted. Also Runtime.evaluate with awaitPromise is not supported, so instead we poll for the promise to be done.

[hansottowirtz]

If you want to use these packages, they are published to npm: @adobe-fixed-uxp/uxp-devtools-helper, @adobe-fixed-uxp/uxp-devtools-cli and @adobe-fixed-uxp/uxp-devtools-core.

Changes in this PR:

• Remove inspect-frontend
• Remove templates
• Remove webdriver
• Remove feature package
• Change to Typescript
• Use pnpm and pnpm changesets
• Fix closing server
• Add Github Actions
• Setup postinstall correctly for uxp-devtools-helper
• Make multiple devtools clients possible
• Node 20 needed

I use this branch in https://github.com/bubblydoo/uxp-toolkit
e.g. you can now run:

# Opens devtools in Chrome
pnpm --allow-build=@adobe-fixed-uxp/uxp-devtools-helper dlx @bubblydoo/uxp-cli open-devtools

or

# Starts an MCP server for Photoshop
pnpm --allow-build=@adobe-fixed-uxp/uxp-devtools-helper dlx @bubblydoo/photoshop-mcp

I already opened this PR once in 2023, but now I did it a bit more thorough (with a lot of Claude help), see #10

[jardicc]

I like that you took care of this. But I personally used Webdriver for very valuable e2e testing. But also hard to configure correctly. I think you don't count on E2E tests here anymore, right?

[hansottowirtz]

That's interesting to know! I mainly made these changes to get Vitest to work over Chrome Devtools Protocol, which is now working in https://github.com/bubblydoo/uxp-toolkit/tree/main/packages/vitest-pool-uxp.
Is there any chance you can change your webdriver code to CDP code (e.g. with Puppeteer)? Or do you have these tests published anywhere open source so I can take a look?

[jardicc]

It is right here. In the templates you are about to remove as well: packages/uxp-templates-pack/uxp-wdio-automation-template/sample-tests/specs/starterScript.js

It uses wdio... there is not to much of documentation it was difficult to figure out how it actually works. Adobe uses robot.js as dependency which also uses C++ node library that can take control over your mouse and keyboard for more complex UI tests.

[jardicc]

Otherwise, I was playing with idea to have some CDP -> DAP -> CDP adapter. So it would be possible to debug in VSCode rather than UDT. https://microsoft.github.io/debug-adapter-protocol/

[hansottowirtz]

Looking at wdio.conf.js, I think this "debuggerAddress" is also just a CDP address, so I think this should not be too hard to get to work.

In the Vitest integration I made sure debugging works, e.g. inside packages/uxp-tookit you can run UXP_INSPECT=1 pnpm run test:uxp debugger --run, it will wait for you to open the devtools link in Chrome, and then it will wait on the "debugger" statement inside the "debugger.uxp-test.ts" file.

[jardicc]

Otherwise, if you look under the hood of UDT inside it looks more or less like in this repo. They just packed it into .asar archive including source code and all node modules. Therefore size +1GB :-D

[hansottowirtz]

Yes I also noticed it, but it's not really needed to use it in my opinion and that's why I deleted it. If you run the open-devtools command I posted above, you can just use Chrome to debug the apps and use the latest Devtools version.

[hansottowirtz]

I actually got the debugger in VSCode to work with Vitest. I don't know how to automatically derive the websocketAddress from the terminal, but it works with this launch.json:

{
"version": "0.2.0",
"configurations": [
{
"name": "Attach to websocket",
"type": "node",
"request": "attach",
"websocketAddress": "ws://127.0.0.1:14002/socket/cdt/a57f319c-5e63-42cd-a308-61dac5edbb2b"
}
]
}

[jardicc]

Do you find any match with adress you need in these responses?

[hansottowirtz]

I'm not sure if they are the same but they look similar. I'm not very sure why there are all these types of urls: /socket/cdt/<uuid>, /devtools/browser/<uuid> and /devtools/page/<uuid>. /socket/browser_cdt/<uuid> and /socket/cli also exist.
Where did you get this ":9123" port from?

[jardicc]

Back in the old days of UXP you could add debug file in same directory as your manifest file and specify port number for built-in Chrome Node.js debugger that would connect via CDP. This was before UDT existed. Later somewhere around PS 2023-2024 it broke.

[hansottowirtz]

I did some more research on webdriver and it seems difficult to handle properly. It's a big protocol that is quite different from CDP, you can also maximize windows, etc. The existing package Adobe created was more of a bridge to CDP, and didn't support a lot of things and seems a bit hacky to me.
I will at least try to make a Puppeteer transport first.

[hansottowirtz]

I made a @bubblydoo/uxp-puppeteer-transport package which you can use with Puppeteer, see for example:
https://github.com/bubblydoo/uxp-toolkit/blob/main/packages/example-puppeteer-integration/src/run.ts
(it's mostly vibecoded but it works)

The difficulty is that UXP CDP does not support pages etc, so those requests are intercepted. Also Runtime.evaluate with awaitPromise is not supported, so instead we poll for the promise to be done.

[hansottowirtz]

If you want to use these packages, they are published to npm: @adobe-fixed-uxp/uxp-devtools-helper, @adobe-fixed-uxp/uxp-devtools-cli and @adobe-fixed-uxp/uxp-devtools-core.

Changes in this PR:

• Remove inspect-frontend
• Remove templates
• Remove webdriver
• Remove feature package
• Change to Typescript
• Use pnpm and pnpm changesets
• Fix closing server
• Add Github Actions
• Setup postinstall correctly for uxp-devtools-helper
• Make multiple devtools clients possible
• Node 20 needed

I use this branch in https://github.com/bubblydoo/uxp-toolkit
e.g. you can now run:

# Opens devtools in Chrome
pnpm --allow-build=@adobe-fixed-uxp/uxp-devtools-helper dlx @bubblydoo/uxp-cli open-devtools

or

# Starts an MCP server for Photoshop
pnpm --allow-build=@adobe-fixed-uxp/uxp-devtools-helper dlx @bubblydoo/photoshop-mcp

I already opened this PR once in 2023, but now I did it a bit more thorough (with a lot of Claude help), see #10

[jardicc]

I like that you took care of this. But I personally used Webdriver for very valuable e2e testing. But also hard to configure correctly. I think you don't count on E2E tests here anymore, right?

[hansottowirtz]

That's interesting to know! I mainly made these changes to get Vitest to work over Chrome Devtools Protocol, which is now working in https://github.com/bubblydoo/uxp-toolkit/tree/main/packages/vitest-pool-uxp.
Is there any chance you can change your webdriver code to CDP code (e.g. with Puppeteer)? Or do you have these tests published anywhere open source so I can take a look?

[jardicc]

It is right here. In the templates you are about to remove as well: packages/uxp-templates-pack/uxp-wdio-automation-template/sample-tests/specs/starterScript.js

It uses wdio... there is not to much of documentation it was difficult to figure out how it actually works. Adobe uses robot.js as dependency which also uses C++ node library that can take control over your mouse and keyboard for more complex UI tests.

[jardicc]

Otherwise, I was playing with idea to have some CDP -> DAP -> CDP adapter. So it would be possible to debug in VSCode rather than UDT. https://microsoft.github.io/debug-adapter-protocol/

[hansottowirtz]

Looking at wdio.conf.js, I think this "debuggerAddress" is also just a CDP address, so I think this should not be too hard to get to work.

In the Vitest integration I made sure debugging works, e.g. inside packages/uxp-tookit you can run UXP_INSPECT=1 pnpm run test:uxp debugger --run, it will wait for you to open the devtools link in Chrome, and then it will wait on the "debugger" statement inside the "debugger.uxp-test.ts" file.

[jardicc]

Otherwise, if you look under the hood of UDT inside it looks more or less like in this repo. They just packed it into .asar archive including source code and all node modules. Therefore size +1GB :-D

[hansottowirtz]

Yes I also noticed it, but it's not really needed to use it in my opinion and that's why I deleted it. If you run the open-devtools command I posted above, you can just use Chrome to debug the apps and use the latest Devtools version.

[hansottowirtz]

I actually got the debugger in VSCode to work with Vitest. I don't know how to automatically derive the websocketAddress from the terminal, but it works with this launch.json:

{
"version": "0.2.0",
"configurations": [
{
"name": "Attach to websocket",
"type": "node",
"request": "attach",
"websocketAddress": "ws://127.0.0.1:14002/socket/cdt/a57f319c-5e63-42cd-a308-61dac5edbb2b"
}
]
}

[jardicc]

Do you find any match with adress you need in these responses?

[hansottowirtz]

I'm not sure if they are the same but they look similar. I'm not very sure why there are all these types of urls: /socket/cdt/<uuid>, /devtools/browser/<uuid> and /devtools/page/<uuid>. /socket/browser_cdt/<uuid> and /socket/cli also exist.
Where did you get this ":9123" port from?

[jardicc]

Back in the old days of UXP you could add debug file in same directory as your manifest file and specify port number for built-in Chrome Node.js debugger that would connect via CDP. This was before UDT existed. Later somewhere around PS 2023-2024 it broke.

[hansottowirtz]

I did some more research on webdriver and it seems difficult to handle properly. It's a big protocol that is quite different from CDP, you can also maximize windows, etc. The existing package Adobe created was more of a bridge to CDP, and didn't support a lot of things and seems a bit hacky to me.
I will at least try to make a Puppeteer transport first.

[hansottowirtz]

I made a @bubblydoo/uxp-puppeteer-transport package which you can use with Puppeteer, see for example:
https://github.com/bubblydoo/uxp-toolkit/blob/main/packages/example-puppeteer-integration/src/run.ts
(it's mostly vibecoded but it works)

The difficulty is that UXP CDP does not support pages etc, so those requests are intercepted. Also Runtime.evaluate with awaitPromise is not supported, so instead we poll for the promise to be done.

[hansottowirtz]

If you want to use these packages, they are published to npm: @adobe-fixed-uxp/uxp-devtools-helper, @adobe-fixed-uxp/uxp-devtools-cli and @adobe-fixed-uxp/uxp-devtools-core.

Changes in this PR:

• Remove inspect-frontend
• Remove templates
• Remove webdriver
• Remove feature package
• Change to Typescript
• Use pnpm and pnpm changesets
• Fix closing server
• Add Github Actions
• Setup postinstall correctly for uxp-devtools-helper
• Make multiple devtools clients possible
• Node 20 needed

I use this branch in https://github.com/bubblydoo/uxp-toolkit
e.g. you can now run:

# Opens devtools in Chrome
pnpm --allow-build=@adobe-fixed-uxp/uxp-devtools-helper dlx @bubblydoo/uxp-cli open-devtools

or

# Starts an MCP server for Photoshop
pnpm --allow-build=@adobe-fixed-uxp/uxp-devtools-helper dlx @bubblydoo/photoshop-mcp

I already opened this PR once in 2023, but now I did it a bit more thorough (with a lot of Claude help), see #10

[jardicc]

I like that you took care of this. But I personally used Webdriver for very valuable e2e testing. But also hard to configure correctly. I think you don't count on E2E tests here anymore, right?

[hansottowirtz]

That's interesting to know! I mainly made these changes to get Vitest to work over Chrome Devtools Protocol, which is now working in https://github.com/bubblydoo/uxp-toolkit/tree/main/packages/vitest-pool-uxp.
Is there any chance you can change your webdriver code to CDP code (e.g. with Puppeteer)? Or do you have these tests published anywhere open source so I can take a look?

[jardicc]

It is right here. In the templates you are about to remove as well: packages/uxp-templates-pack/uxp-wdio-automation-template/sample-tests/specs/starterScript.js

It uses wdio... there is not to much of documentation it was difficult to figure out how it actually works. Adobe uses robot.js as dependency which also uses C++ node library that can take control over your mouse and keyboard for more complex UI tests.

[jardicc]

Otherwise, I was playing with idea to have some CDP -> DAP -> CDP adapter. So it would be possible to debug in VSCode rather than UDT. https://microsoft.github.io/debug-adapter-protocol/

[hansottowirtz]

Looking at wdio.conf.js, I think this "debuggerAddress" is also just a CDP address, so I think this should not be too hard to get to work.

In the Vitest integration I made sure debugging works, e.g. inside packages/uxp-tookit you can run UXP_INSPECT=1 pnpm run test:uxp debugger --run, it will wait for you to open the devtools link in Chrome, and then it will wait on the "debugger" statement inside the "debugger.uxp-test.ts" file.

[jardicc]

Otherwise, if you look under the hood of UDT inside it looks more or less like in this repo. They just packed it into .asar archive including source code and all node modules. Therefore size +1GB :-D

[hansottowirtz]

Yes I also noticed it, but it's not really needed to use it in my opinion and that's why I deleted it. If you run the open-devtools command I posted above, you can just use Chrome to debug the apps and use the latest Devtools version.

[hansottowirtz]

I actually got the debugger in VSCode to work with Vitest. I don't know how to automatically derive the websocketAddress from the terminal, but it works with this launch.json:

{
"version": "0.2.0",
"configurations": [
{
"name": "Attach to websocket",
"type": "node",
"request": "attach",
"websocketAddress": "ws://127.0.0.1:14002/socket/cdt/a57f319c-5e63-42cd-a308-61dac5edbb2b"
}
]
}

[jardicc]

Do you find any match with adress you need in these responses?

[hansottowirtz]

I'm not sure if they are the same but they look similar. I'm not very sure why there are all these types of urls: /socket/cdt/<uuid>, /devtools/browser/<uuid> and /devtools/page/<uuid>. /socket/browser_cdt/<uuid> and /socket/cli also exist.
Where did you get this ":9123" port from?

[jardicc]

Back in the old days of UXP you could add debug file in same directory as your manifest file and specify port number for built-in Chrome Node.js debugger that would connect via CDP. This was before UDT existed. Later somewhere around PS 2023-2024 it broke.

[hansottowirtz]

I did some more research on webdriver and it seems difficult to handle properly. It's a big protocol that is quite different from CDP, you can also maximize windows, etc. The existing package Adobe created was more of a bridge to CDP, and didn't support a lot of things and seems a bit hacky to me.
I will at least try to make a Puppeteer transport first.

[hansottowirtz]

I made a @bubblydoo/uxp-puppeteer-transport package which you can use with Puppeteer, see for example:
https://github.com/bubblydoo/uxp-toolkit/blob/main/packages/example-puppeteer-integration/src/run.ts
(it's mostly vibecoded but it works)

The difficulty is that UXP CDP does not support pages etc, so those requests are intercepted. Also Runtime.evaluate with awaitPromise is not supported, so instead we poll for the promise to be done.

[hansottowirtz]

If you want to use these packages, they are published to npm: @adobe-fixed-uxp/uxp-devtools-helper, @adobe-fixed-uxp/uxp-devtools-cli and @adobe-fixed-uxp/uxp-devtools-core.

Changes in this PR:

• Remove inspect-frontend
• Remove templates
• Remove webdriver
• Remove feature package
• Change to Typescript
• Use pnpm and pnpm changesets
• Fix closing server
• Add Github Actions
• Setup postinstall correctly for uxp-devtools-helper
• Make multiple devtools clients possible
• Node 20 needed

I use this branch in https://github.com/bubblydoo/uxp-toolkit
e.g. you can now run:

# Opens devtools in Chrome
pnpm --allow-build=@adobe-fixed-uxp/uxp-devtools-helper dlx @bubblydoo/uxp-cli open-devtools

or

# Starts an MCP server for Photoshop
pnpm --allow-build=@adobe-fixed-uxp/uxp-devtools-helper dlx @bubblydoo/photoshop-mcp

I already opened this PR once in 2023, but now I did it a bit more thorough (with a lot of Claude help), see #10

[jardicc]

I like that you took care of this. But I personally used Webdriver for very valuable e2e testing. But also hard to configure correctly. I think you don't count on E2E tests here anymore, right?

[hansottowirtz]

That's interesting to know! I mainly made these changes to get Vitest to work over Chrome Devtools Protocol, which is now working in https://github.com/bubblydoo/uxp-toolkit/tree/main/packages/vitest-pool-uxp.
Is there any chance you can change your webdriver code to CDP code (e.g. with Puppeteer)? Or do you have these tests published anywhere open source so I can take a look?

[jardicc]

It is right here. In the templates you are about to remove as well: packages/uxp-templates-pack/uxp-wdio-automation-template/sample-tests/specs/starterScript.js

It uses wdio... there is not to much of documentation it was difficult to figure out how it actually works. Adobe uses robot.js as dependency which also uses C++ node library that can take control over your mouse and keyboard for more complex UI tests.

[jardicc]

Otherwise, I was playing with idea to have some CDP -> DAP -> CDP adapter. So it would be possible to debug in VSCode rather than UDT. https://microsoft.github.io/debug-adapter-protocol/

[hansottowirtz]

Looking at wdio.conf.js, I think this "debuggerAddress" is also just a CDP address, so I think this should not be too hard to get to work.

In the Vitest integration I made sure debugging works, e.g. inside packages/uxp-tookit you can run UXP_INSPECT=1 pnpm run test:uxp debugger --run, it will wait for you to open the devtools link in Chrome, and then it will wait on the "debugger" statement inside the "debugger.uxp-test.ts" file.

[jardicc]

Otherwise, if you look under the hood of UDT inside it looks more or less like in this repo. They just packed it into .asar archive including source code and all node modules. Therefore size +1GB :-D

[hansottowirtz]

Yes I also noticed it, but it's not really needed to use it in my opinion and that's why I deleted it. If you run the open-devtools command I posted above, you can just use Chrome to debug the apps and use the latest Devtools version.

[hansottowirtz]

I actually got the debugger in VSCode to work with Vitest. I don't know how to automatically derive the websocketAddress from the terminal, but it works with this launch.json:

{
"version": "0.2.0",
"configurations": [
{
"name": "Attach to websocket",
"type": "node",
"request": "attach",
"websocketAddress": "ws://127.0.0.1:14002/socket/cdt/a57f319c-5e63-42cd-a308-61dac5edbb2b"
}
]
}

[jardicc]

Do you find any match with adress you need in these responses?

[hansottowirtz]

I'm not sure if they are the same but they look similar. I'm not very sure why there are all these types of urls: /socket/cdt/<uuid>, /devtools/browser/<uuid> and /devtools/page/<uuid>. /socket/browser_cdt/<uuid> and /socket/cli also exist.
Where did you get this ":9123" port from?

[jardicc]

Back in the old days of UXP you could add debug file in same directory as your manifest file and specify port number for built-in Chrome Node.js debugger that would connect via CDP. This was before UDT existed. Later somewhere around PS 2023-2024 it broke.

[hansottowirtz]

I did some more research on webdriver and it seems difficult to handle properly. It's a big protocol that is quite different from CDP, you can also maximize windows, etc. The existing package Adobe created was more of a bridge to CDP, and didn't support a lot of things and seems a bit hacky to me.
I will at least try to make a Puppeteer transport first.

[hansottowirtz]

I made a @bubblydoo/uxp-puppeteer-transport package which you can use with Puppeteer, see for example:
https://github.com/bubblydoo/uxp-toolkit/blob/main/packages/example-puppeteer-integration/src/run.ts
(it's mostly vibecoded but it works)

The difficulty is that UXP CDP does not support pages etc, so those requests are intercepted. Also Runtime.evaluate with awaitPromise is not supported, so instead we poll for the promise to be done.

[hansottowirtz]

If you want to use these packages, they are published to npm: @adobe-fixed-uxp/uxp-devtools-helper, @adobe-fixed-uxp/uxp-devtools-cli and @adobe-fixed-uxp/uxp-devtools-core.

Changes in this PR:

• Remove inspect-frontend
• Remove templates
• Remove webdriver
• Remove feature package
• Change to Typescript
• Use pnpm and pnpm changesets
• Fix closing server
• Add Github Actions
• Setup postinstall correctly for uxp-devtools-helper
• Make multiple devtools clients possible
• Node 20 needed

I use this branch in https://github.com/bubblydoo/uxp-toolkit
e.g. you can now run:

# Opens devtools in Chrome
pnpm --allow-build=@adobe-fixed-uxp/uxp-devtools-helper dlx @bubblydoo/uxp-cli open-devtools

or

# Starts an MCP server for Photoshop
pnpm --allow-build=@adobe-fixed-uxp/uxp-devtools-helper dlx @bubblydoo/photoshop-mcp

I already opened this PR once in 2023, but now I did it a bit more thorough (with a lot of Claude help), see #10

[jardicc]

I like that you took care of this. But I personally used Webdriver for very valuable e2e testing. But also hard to configure correctly. I think you don't count on E2E tests here anymore, right?

[hansottowirtz]

That's interesting to know! I mainly made these changes to get Vitest to work over Chrome Devtools Protocol, which is now working in https://github.com/bubblydoo/uxp-toolkit/tree/main/packages/vitest-pool-uxp.
Is there any chance you can change your webdriver code to CDP code (e.g. with Puppeteer)? Or do you have these tests published anywhere open source so I can take a look?

[jardicc]

It is right here. In the templates you are about to remove as well: packages/uxp-templates-pack/uxp-wdio-automation-template/sample-tests/specs/starterScript.js

It uses wdio... there is not to much of documentation it was difficult to figure out how it actually works. Adobe uses robot.js as dependency which also uses C++ node library that can take control over your mouse and keyboard for more complex UI tests.

[jardicc]

Otherwise, I was playing with idea to have some CDP -> DAP -> CDP adapter. So it would be possible to debug in VSCode rather than UDT. https://microsoft.github.io/debug-adapter-protocol/

[hansottowirtz]

Looking at wdio.conf.js, I think this "debuggerAddress" is also just a CDP address, so I think this should not be too hard to get to work.

In the Vitest integration I made sure debugging works, e.g. inside packages/uxp-tookit you can run UXP_INSPECT=1 pnpm run test:uxp debugger --run, it will wait for you to open the devtools link in Chrome, and then it will wait on the "debugger" statement inside the "debugger.uxp-test.ts" file.

[jardicc]

Otherwise, if you look under the hood of UDT inside it looks more or less like in this repo. They just packed it into .asar archive including source code and all node modules. Therefore size +1GB :-D

[hansottowirtz]

Yes I also noticed it, but it's not really needed to use it in my opinion and that's why I deleted it. If you run the open-devtools command I posted above, you can just use Chrome to debug the apps and use the latest Devtools version.

[hansottowirtz]

I actually got the debugger in VSCode to work with Vitest. I don't know how to automatically derive the websocketAddress from the terminal, but it works with this launch.json:

{
"version": "0.2.0",
"configurations": [
{
"name": "Attach to websocket",
"type": "node",
"request": "attach",
"websocketAddress": "ws://127.0.0.1:14002/socket/cdt/a57f319c-5e63-42cd-a308-61dac5edbb2b"
}
]
}

[jardicc]

Do you find any match with adress you need in these responses?

[hansottowirtz]

I'm not sure if they are the same but they look similar. I'm not very sure why there are all these types of urls: /socket/cdt/<uuid>, /devtools/browser/<uuid> and /devtools/page/<uuid>. /socket/browser_cdt/<uuid> and /socket/cli also exist.
Where did you get this ":9123" port from?

[jardicc]

Back in the old days of UXP you could add debug file in same directory as your manifest file and specify port number for built-in Chrome Node.js debugger that would connect via CDP. This was before UDT existed. Later somewhere around PS 2023-2024 it broke.

[hansottowirtz]

I did some more research on webdriver and it seems difficult to handle properly. It's a big protocol that is quite different from CDP, you can also maximize windows, etc. The existing package Adobe created was more of a bridge to CDP, and didn't support a lot of things and seems a bit hacky to me.
I will at least try to make a Puppeteer transport first.

[hansottowirtz]

I made a @bubblydoo/uxp-puppeteer-transport package which you can use with Puppeteer, see for example:
https://github.com/bubblydoo/uxp-toolkit/blob/main/packages/example-puppeteer-integration/src/run.ts
(it's mostly vibecoded but it works)

The difficulty is that UXP CDP does not support pages etc, so those requests are intercepted. Also Runtime.evaluate with awaitPromise is not supported, so instead we poll for the promise to be done.