Hi everyone,
Is this tool lazy or does it have a timer to shut it down?
I have been working with it from 10:00AM till 5:00PM, it is the fourth time it vanishes. The more I work with it, the shorter delays between failures.
Is this normal or ???
Is there a remedy?
It does this, it seems, when you have it set to “Watch” a particular plugin, i.e. reload it after saving a coding change. After some unspecified number of reloads, it gets stuck in some loop (based on the whirring I hear from my computer) and then shuts down and closes. At least that’s the behavior on my Windows computer. Frustrating, but I just restart it and reload the panel. Mine shuts down about 4 times every hour, so it’s apparently a lot lazier than yours.
The watch function has always been really slow for me, so I started to just refresh it manually. Those 2-3 clicks feel a lot faster and more responsive than the unnecessary long delay from the watch refresh 
I think I’ve read something in the update notes that there were problems with projects including node_modules folders, but I’m quite sure that it’s still slow.
Thanks for your reply.
I will have to change my workflow.
Thanks for your reply
The UDT should not be crashing, quitting, or slow on reloads, even on Windows (w/ the exception of including the node_modules folder – that will slow everything down – so check that first.)
I’m forwarding this to the team – you may be asked to provide some logs to help diagnose the issue you’re facing.
1 Like
But how do we exclude the node_modules folder in the first place?
I just tried the watch function again and it’s completely unusable for me, it gets slower and slower with each refresh until it freezes or crashes.
The key is to have a separate dist folder. Our Photoshop React samples are already doing this, but our XD React samples don’t do this yet (it’s in process).
You’ll want to tweak the webpack.config.js file so that your plugin’s build files are emitted to dist (along with copying the manifest.json and any assets). An example of this is here: uxp-photoshop-plugin-samples/webpack.config.js at main · AdobeDocs/uxp-photoshop-plugin-samples · GitHub (note the devtools setting will not work on XD – use source-map instead).
At this point, you can either add dist/manifest.json to the UDT, or, you can keep the existing setting and tell UDT where the build folder is (••• > Options > Advanced > put path to dist > Save).
Alternatively, you can try moving a copy of your plugin’s manifest.json file into your src older. Then, add that folder to the UDT and tell it that the build is in the parent directory. This will be a little slower than the above because UDT may have to copy your src files, but still faster than node_modules. You can do this with ••• > Options > Advanced > ../ in path > Save)
1 Like
@simonhenke what version of UDT are you on? Can you ensure that you are on UDT v1.2.0.3, the latest on CCD? Node_modules are ignored by default during watch if you are on v1.2.
If you are still seeing issues, do share the UDT logs present in temp directory(C:\Users<username>\AppData\Roaming\Adobe\Adobe UXP Developer Tool\Logs). Or a sample plugin for investigation would also be helpful.
Hi, yes I have version 1.2.0.3
I copied all the CCS files to the extension folder. This gives less UDT shutdowns and I think better panel performance.
I attached a panel and 3 logs.
But I think I solved a lot by adding the third line in index.js. Do I need others???
Debugger.zip (578.2 KB)
I’m not entirely clear on the state of your plugin before the changes, but a couple notes:
- All your static assets should be local to the plugin and not loaded remotely. Loading remote CSS files is definitely going to slow down startup, and cause issues for users who are offline. Maybe that’s not what your plugin was doing, though – I’m reading between the lines.
- The third line (
const UXP = require("uxp").app) does nothing (it’ll just assignundefinedto UXP, since there’s noappproperty in the UXP module. The only thing I can think of is maybe it’s forcing the UXP module to load a little earlier – you might want to do something likeconst UXP = require("uxp"), and then replace your other uses ofrequire("uxp")withUXP. Either way, this shouldn’t be impacting UDT stability. :-/
My experience with UDT is seemless, since I understood that for some reason, the local path of a plugin and it’s parent shouldn’t contain exotic characters or too many spaces. 
You might want to take a look at your plugin full path name 
FYI, I have installed the Debugger that you provided, without modiying a single line.
First I installed it in hdd1 / soft / uxp / Plug Ins / Testing / Panel 01 / Debugger. That’s an extrernal hard drive. UDT watches it OK, and reacts almost instantly to any changes in that folder provided you have set it to Watch in UDT of course.
However, when I install it in [[ DATA ]] / Debugger, the Watch link gets broken!
So, the install path matters for the Watch to… watch!
Further, if your plugin in hosted on a distant storage (LAN/NAS)(which is not really recommended), the Watch link get broken too.
FWIW, I’ve experienced UDT crashing quite often; the Watch wasn’t working… I always implement a Reaload button on the GUI or as a Flyout Menu option…but…It used to drive me mad when I started UXP in Nov.2020!
Since then, working on 7 new UXP panels for over 150 days, UDT is stable when I pay attention to the install work path.
PS: I’m working with Vanilla JS, and have tested these scenarios on both Mac and PC.
I’m on version 1.2.0.3, too. Also, my plugin has a separate dist folder, so theoretically node_modules shouldn’t be the problem.
I took a brief look at the logs but couldn’t see anything suspicious, but I might have to do further investigations. I planned to try it out with one of the starter plugins also, but it might take some days until I have time for that. I’ll post my results here once I’ve done the testing.
Which function did you use for the reload functionality?
are you using React or vanilla JS? If i remember correctly, the window.location.reload() didn’t do a complete hard reload like the UDT does (in my case). For example reload a component that had a runtime error.
Thank you so much for your help. But don’t waste to much time checking those files, I relocated my UXP folder from disk drive D:\Entrepot\LR-PE\UXP → SSD C:\UXP. All CSS folders are located in the the main extension folder.
RESULTS: I have been operating for the last 9 hours without shutdown.
As Pierre_G said I use this on vanilla JS :
document.getElementById(“btnThree”).addEventListener(“click”, function () {location.reload()});
REACT for me is = ??? 
Vanilla for now. Would love to jump in React in a near future…
I believe it’s actually a memory leak when you’re using the Watch feature. I’ve actually stopped using Watch because it gets slower and slower every time it reloads until finally it stops responding altogether.
My advice is to not use Watch and just Reload each time you compile the code. You’ll be much happier with the performance!
1 Like