2

I'm new to Electron, and trying to help maintain an application whose developer has left. The resources/app folder consists of (at least) three things:

  • The app/lib/bundle.js, which contains the entire application, bundled and minified. This is what the app seems to actually run.
  • Node modules for all the code written by the developer. These are in TypeScript, and are in the structure node_modules/@mainmodule/submodule/src/.../something.ts. Each of these also has a node_modules/@mainmodule/submodule/package.json and node_modules/@mainmodule/submodule/tsconfig.json
  • Finally, for each of these, a corresponding lib folder: node_modules/@mainmodule/submodule/src/.../something.js. The lib folder has Javascript corresponding to each of the TypeScript, as well as map files showing how they correspond. It is these Javascript files that are minified and included in the bundle, which is actually run.

The source TypeScript is relatively clear and I can follow most of it. But to really understand it I need to set breakpoints on it and run it in a debugger (e.g. VS Code). However, when running the app, Electron doesn't run it from the TypeScript (in src), or even the individual Javascript (in lib), but rather from bundle.js. Bundle.js is a giant file that, besides being minified, is too big to even load properly in my editor.

My question

How can I tell Electron to run the app not from the bundle.js, but from the individual src/...ts TypeScript, or, failing that, from the individual src/...js JavaScript?

If that's not possible, what is the proper way to use a debugger, given the source, when the Electron application is bundled? I have full source but, when I invoke Electron, it runs out of the bundle: how I can change this?

I'm new to Electron and Node, so if I'm making an elementary mistake, please clarify.

Update with progress so far

I've made a lot of progress in getting down to source, but not all the way there.

The Electron app starts with electron-main.js, which loads things like server.js and other files. These all run from source.

Eventually, it creates a minimal window with the following code:

<head>
...
  <script type="text/javascript" src="./bundle.js" charset="utf-8"></script>
</head>

bundle.js is then loaded in the window. The files is far too big and unscrutable (minified) to be of much use. But, as I said, the source is all available too.

However, bundle.map.js contains is complete: it contains sources, names, mappings, sourcesContent, which is enough, in principle, to reconstruct everything. Moreover, for almost all of the sources, the corresponding source file is available and obvious.

I believe I need to replace the <script type="text/javascript" src="./bundle.js" charset="utf-8"></script> with a includer.js which:

  • Includes all files for which I can figure out their matching source file
  • Uses the sourcesContent for anything else

/Progress to date...

SRobertJames
  • 8,210
  • 14
  • 60
  • 107
  • How the `bundle.js` prepared? – Alex Wayne Mar 15 '22 at 22:48
  • From What I understand bundle.js is prepared by some sort of bundling software like webpack which should contain most of the relevant code of the application but in minfied form. Technically this instance can be modified to achieve what you want but its not legible and easy to do especially when you are dealing with large code. node_modules contains all the application dependency packages which the application uses. To handle this you would need to find the actual development application that is getting build. After which you need to do your changes and re-build it. – innocent Mar 20 '22 at 18:10
  • Look for an option to add preservation of source mapping in the transpiler step. With the source mapping vscode will allow you to step through the typescript without you needing to mentally map between the intermediaries.https://www.electronjs.org/docs/latest/tutorial/debugging-vscode#:~:text=This%20guide%20goes%20over%20how%20to%20set%20up,Add%20a%20file%20.vscode%2Flaunch.json%20with%20the%20following%20configuration%3A – Jos Verlinde Mar 27 '22 at 14:08

2 Answers2

3

Since the project is set up to run things from a bundle at the moment, it's likely that the project can only run things from the bundle, unless you change the config (which can only be done if you have some idea of what the overall structure is in the first place, which you're trying to get a grasp on to begin with). In other words, the most likely approach to look at how things are interlocking and to analyze and change the logic in the application will be to generate a new bundle.

Very often, the process of generating a new bundle will be contained in the project's root folder's package.json. If you have:

the-big-app/node_modules

then you can probably look at

the-big-app/package.json

and look at the scripts contained within it. There will probably be something along the (very general) lines of:

{
    "name": "the-big-app",
    "scripts": {
        "lint": "eslint .",
        "build": "webpack && tsc --build tsconfig.node.json",
        "watch": "nodemon --exec npm run start -e ts,tsx,scss,html",
        "run": "npx electron build/node/main.js",
        "start": "npm run build && npm run run"
    },

Each of these properties refers to a runnable NPM script. You're likely to have a build script - if you have such a script and type npm run build, it should then generate a new bundle, which can then be executed. If there is no build script, look around to see which other scripts look like they might do something useful, and execute them. (Back up the existing bundle and other files in the directory first, just in case.)

Look at the values for each NPM script property so you can do further research into what they do and how they might relate to turning the source code into something that runs. Just for example, above, doing

"build": "webpack && tsc --build tsconfig.node.json",

in my app, will

(1) Run Webpack to construct a bundle for the renderer process

(2) Run tsc to compile the TypeScript code inside the-big-app/src/main-process/ into JavaScript that can then be executed by Electron

Look for something similar in your package.json to see what's happening, which will inform you on how it can be tweaked and debugged.

As Electron's docs say, the browser code can be debugged via the devtools. Debugging the main process is harder - you may need to call Electron with the inspect flag, among others.

As for the question of if/how things can be run directly from source TypeScript and not from a bundle - it's possible to do this for the main process with ts-node (2). I don't think it's possible for a renderer process, because the "page" needs to see a plain .js file, like any webpage - and, similarly, can't run TypeScript directly, also like normal browsers and webpages can't run TypeScript directly.

CertainPerformance
  • 356,069
  • 52
  • 309
  • 320
  • Interestingly enough, `the-big-app/package.json` doesn't have a single `scripts` section. The individual submodules have detailed `package.json` with things like `jest` and `testMatch`, but also no `scripts` section. – SRobertJames Mar 16 '22 at 01:50
  • But, do I even need the scripts? I know the `electron-main.js` which, BTW, has many references to `// Check whether we are in bundled application or development mode.... const devMode = process.defaultApp || node_modules[/]electron[/]/.test(process.execPath);` . And I have the references from `electron-main.js` to other JS files. Could I somehow tell Electron: Run `electron-main` but do not use the `bundle.js`, just use individual files? – SRobertJames Mar 16 '22 at 01:55
  • No scripts? That's unusual, and usually indicative of a bad setup, since it means that people working on the code in the future (like you) basically have to *guess* how to do things, rather than having it written out somewhere. It could be that one of the .js files runs the build process. (Eg `node build.js` runs the build process) And there's no readme.md either? – CertainPerformance Mar 16 '22 at 02:08
  • Since there are comments about it, it sounds likely that there's a way, but without being able to see everything you have to work with (which'd be too large for a MCVE anyway) I'm not seeing another starting point of where to start looking, other than looking through each script starting from the top level to see if it looks promising. – CertainPerformance Mar 16 '22 at 02:08
1

To add to the above answer, I have a Typescript React app that uses Webpack, which you can compare against. You can step through its code for both the main and renderer processes:

You also need to build with sourcemaps enabled. Once done you can step through Typescript code line by line.

Gary Archer
  • 22,534
  • 2
  • 12
  • 24