Built app doesn't start

Development
1

I built the app with yarn run dist. The resulting application does not start.

It seems a few paths have not been updated or the assets were not copied properly.
I am a bit busy right now, so I just wanted to put it out there.

I will have a look at it on the weekend. Who knows, maybe somebody will beat me to it. :wink:

Uncaught Error: Cannot find module '../lib/eventManager'
Require stack:
- /Applications/Joplin.app/Contents/Resources/app.asar/app.js
- /Applications/Joplin.app/Contents/Resources/app.asar/index.html
    at Module._resolveFilename (internal/modules/cjs/loader.js:892)
    at Function.o._resolveFilename (electron/js2c/renderer_init.js:29)
    at Module._load (internal/modules/cjs/loader.js:737)
    at Function.f._load (electron/js2c/asar_bundle.js:5)
    at Function.o._load (electron/js2c/renderer_init.js:29)
    at Module.require (internal/modules/cjs/loader.js:964)
    at require (internal/modules/cjs/helpers.js:88)
    at Object.<anonymous> (app.js:72)
    at Object.<anonymous> (app.js:519)
    at Module._compile (internal/modules/cjs/loader.js:1083)

​```
2

Yep, I can replicate that.

First time I tried to launch the appimage it spawns a bunch of processes but fails to do anything. Launching a second time (without manually killing those processes) it launches an electron window but no actual Joplin app spawns. That electron window is then just... stuck... and has to be killed.

I got the same error from the electron app dev tools:

Uncaught Error: Cannot find module '../lib/eventManager'
Require stack:
- /tmp/.mount_JoplinD3eYGv/resources/app.asar/app.js
- /tmp/.mount_JoplinD3eYGv/resources/app.asar/index.html
    at Module._resolveFilename (internal/modules/cjs/loader.js:892)
    at Function.o._resolveFilename (electron/js2c/renderer_init.js:29)
    at Module._load (internal/modules/cjs/loader.js:737)
    at Function.f._load (electron/js2c/asar_bundle.js:5)
    at Function.o._load (electron/js2c/renderer_init.js:29)
    at Module.require (internal/modules/cjs/loader.js:964)
    at require (internal/modules/cjs/helpers.js:88)
    at Object.<anonymous> (app.ts:65)
    at Object.<anonymous> (app.ts:601)
    at Module._compile (internal/modules/cjs/loader.js:1083)
```
3

Yes that's VSCode which sets the paths incorrectly. That eventManager path just needs to be updated.

4

That worked, i set it from ../lib to @joplin/lib and it now runs at least

5

Fixing this particular issue was not the real intention of my post.

It could still be possible that we run into other problems, because the path in another file is incorrectly set. I was wondering, if there's some automated way to make sure that this is not the case.
e.g. writing a script that checks all files (.ts and .js) outside of packages/lib whether they import anything that doesn't start with @joplin.

If so, I can do that. I just need guidance whether there is a pattern how files/modules are referenced. IMO this is a bit wonky and since we don't get compile errors but only runtime errors, this is even more so important.

1 Like
6

I agree, it was just a perfect easy thing an idiot like me could quickly resolve and check that it worked but it makes sense that should be caught when building especially seeing as the dev version works just fine.

7

The fix is great and I saw that you've added it to the source tree already...

Thus, definitely thanks for that.

I just remember that we fixed something like this a while back and then we ran a certain function like export to PDF (can't recall if it really was that function), we got another module not found error.

8

We have this issue now and then because vscode doesn't properly handle monorepos. It's quickly detected though (as in this case) because the app won't start. To automate this, we'd need to somehow start the app from CI and check that it's running properly but we don't have such tests yet.

As for writing a script to parse paths, well, if VScode doesn't detect the bug, TypeScript, npm or Yarn don't either, then we probably won't do much better. It's not that easy to solve because technically the code is actually correct, except that the resulting app won't run.

9

Because it was in the script that was called at start. But this is not so easy to find when running an action like export to ..., Command palette, and so on. Testing this in CI might be hard, unless we use Selenium and go through every possible menu item.

Right, but that's why I was asking for a pattern. When it is ok to use a relative path and when is it required to use the absolute @joplin/ notation?
When we have such a pattern we can test for it.

10

All packages should use absolute paths, except within the lib package itself.

If you want to automate this feel free to give it a try, but it's not a new problem and so far it's never been an actual issue. Someone will usually notice it (usually me, when I manually test the app before release) and the error message makes it easy to find the code. Also perhaps vscode will eventually fix this bug.

11

For the app.ts alone we have the following relative paths:

import PluginRunner from './services/plugins/PluginRunner';
import PlatformImplementation from './services/plugins/PlatformImplementation';
import SpellCheckerServiceDriverNative from './services/spellChecker/SpellCheckerServiceDriverNative';
import bridge from './services/bridge';
import menuCommandNames from './gui/menuCommandNames';
import stateToWhenClauseContext from './services/commands/stateToWhenClauseContext';
import appReducer, { createAppDefaultState } from './app.reducer';
const packageInfo = require('./packageInfo.js');
const { webFrame } = require('electron');
import mainScreenCommands from './gui/MainScreen/commands/index';
import noteEditorCommands from './gui/NoteEditor/commands/index';
import noteListCommands from './gui/NoteList/commands/index';
import noteListControlsCommands from './gui/NoteListControls/commands/index';
import sidebarCommands from './gui/Sidebar/commands/index';
import appCommands from './commands/index';
import { homedir } from 'os';
const electronContextMenu = require('./services/electron-context-menu');
import editorCommandDeclarations from './gui/NoteEditor/editorCommandDeclarations';
import PerFolderSortOrderService from './services/sortOrder/PerFolderSortOrderService';
import checkForUpdates from './checkForUpdates';
import { AppState } from './app.reducer';
	require('./plugins/GotoAnything').default,
12

Out of curiousity what exactly is it in VSCode that causes this to happen? I assume this is some kind of fancy pants setup you have going on there compared to me slumming it essentially only one step up from windows notepad.

13

To be clearer a package should refer to its own files using a relative path, and to any file outside the package using an absolute path.

1 Like
14

Ok, this makes writing such a script rather complicated.

15

It's just default TypeScript support I think. When auto-completing a package, it uses a relative path, which most of the time is fine, however when crossing package boundaries it should use an absolute path, but currently doesn't.

Somehow I think it used to work fine but maybe something got changed in tsc or vscode and it no longer does.

16

2 posts were split to a new topic: Cannot build mobile app