Can't use to run Electron App anymore

After the last pull from master (the problem starts at 34f0a295), I can’t run the app anymore. stops at Compiling /Users/tessus/data/work/joplin/ElectronClient/app/gui/StatusScreen.jsx... and then nothing. I have to click on the Electron icon in the dock and an empty window pops up.

@laurent any ideas?

You can uncomment the openDevTools() line to view the error. But there’s a chance is due to the addition of TypeScript. You need to run npm run tsc from the root to compile the scripts.

Thank you. Yes, that did it. Hmm, I think we should add that to the script. We also compile the jsx files when running What do you think?

P.S.: Actually we should add it to the script. I can create a PR or push it directly…

I thought about it but I think adding it to would slow down launching the app for development. In I’ve added a section suggesting to either use tsc-watch if you’re working on TypeScript files or use tsc once if you’re not. I’ve just recently added TypeScript support so maybe there are better ways to improve the process though.

Ah, I see. It takes about 5 seconds so I don’t think it’s necessarily a problem, because one doesn’t run the app every 10 seconds. But I get what you are saying. If TypeScript files are less used than jsx files it probably is better to use the watch functionality.

I see that npm run tsc is in CliClient/ and seems to be causing this wonderful strangeness with the API docs.

joplin@1.0.0 tsc /Users/laurent/src/joplin

TSFILE: /Users/laurent/src/joplin/ReactNativeClient/lib/JoplinServerApi.js
TSFILE: /Users/laurent/src/joplin/ReactNativeClient/lib/
TSFILE: /Users/laurent/src/joplin/ElectronClient/app/lib/JoplinServerApi.js
TSFILE: /Users/laurent/src/joplin/ElectronClient/app/lib/
TSFILE: /Users/laurent/src/joplin/ElectronClient/app/gui/ShareNoteDialog.js
TSFILE: /Users/laurent/src/joplin/ElectronClient/app/gui/
TSFILE: /Users/laurent/src/joplin/CliClient/build/lib/JoplinServerApi.js
TSFILE: /Users/laurent/src/joplin/CliClient/build/lib/

Redirecting this to /dev/null does make that particular problem go away, but causes the new one of swallowing compiler error messages. Not sure what to do with this one so thought I’d mention it here!

Thanks for the info. see