nteract: Possible regressions with 0.25

OOOOOOOOOOK! Thanks folks for all your patience on this thread. Been a little busy with day job/writing/variety of other shenanigans.

@vivek1729 You followed the correct steps for producing a local production build. Having to increase the allocated heap size is not-problematic since the Electron build does consume quite a bit of memory.

I was able to reproduce the issue on the v0.25 release on macOS. I was not able to reproduce this issue on Windows.

closing/quitting the desktop app (had to ps -ax | grep nteract and then kill) switching of editors resulting in blank page individual windows will not close

I wasn’t able to reproduce these issues on Windows, but I was able to reproduce on macOS. It appears that the unhandled exception from the monaco-editor completely borks all the event handlers in the web page. Users are unable to close the app page in this case because we register event handlers on close inside the JS on the page (as opposed to Electron).

So, in summary, the root cause of the issues above appears to be unhandled exception with the undefined getConfiguration API.

Unfortunately for us, the issue appears to repro inconsistently. I was able to repro on macOS in v0.25 that was auto-updated. @willingc was able to reproduce in a fresh app on the DMG. And it appears that it repros on Linux as well.

As to why this happens, it appears that the getConfiguration API was deprecated in 0.19 (ref). I was a bit suspicious about this so I cracked upon the build application and inspected the app.js file bundled in the app.

$ cd /Applications/nteract.app/Contents/Resources
$ asar extract app.asar nteract-built
$ code nteract-built

Sure enough, a lookup for getConfiguration in that file yields nothing. But getRawOptions is defined.

So somehow, the incorrect version of monaco-editor is being bundled into some applications. Why this is happening? I’m not sure. The inconsistency in reproducibility we are seeing makes this difficult to track down. Next thing I’ll try is to see if the issue reproduces on a fresh build (yarn dist) on macOS.

@vivek1729 Any intuition on why some builds bundle the incorrect version of monaco-editor?

It’s fascinating that the package is auto-updated for Mac and not on Windows. It’s also possible that this happens for some other packages too but we have not yet encountered run time errors with them.

Auto-update is supported on all operating systems, which is what makes this more puzzling. In addition to the fact that @willingc reproduced this on a fresh .app file from a DMG on macOS.

My thinking about how to approach this at this point:

1. Generate the distributed builds for all operating systems (have to do this on macOS because you can only make macOS builds on macOS devices)
2. Inspect the bundled app.js file in each and confirm that the appropriate version of monaco-editor is shipped
3. If so, great, something might’ve gonna awry with the last release
4. If not, investigate why the particular incorrect builds are created

If the October release contains the same issue even after validating that the right bits are included as part of #3, then it very well maybe something about the target machine and not the bundle.

Doing a clean yarn dist might be a good idea. I am not sure if that command installs the node modules again. So, if we can confirm that we had the right version of monaco-editor package installed when we did yarn install or yarn start, then yarn dist should just pick up the same node modules right?

Yep. For what you are proposing (same as step #1 above), we’ll need to do yarn clean && yarn && yarn build:all:ci && yarn dist.

The RELEASING.md documentation in the root of the repo contains docs on this. Should just need to run yarn dist then find the executable in application/desktop/dist.