Skip to content

Instantly share code, notes, and snippets.

Last active April 1, 2023 17:07
  • Star 1 You must be signed in to star a gist
  • Fork 4 You must be signed in to fork a gist
Star You must be signed in to star a gist
What would you like to do?



My project was basically centered towards improving Electron fiddle and it's architecture from a security standpoint. This included the following improvements across the codebase -

  • Integration of fiddle-core: fiddle-core is a package developed by the Electron team which expedites the process of running fiddles from gist/local path with an electron version of choice. Integrating fiddle-core in Electron fiddle deduplicated the most of the logic and also improves the disk space usage by keeping electron versions in a zipped file.
  • Removal of Node environment from the renderer process: This tackles one of the major security consideration of Electron fiddle. Basically, exposing the Node evironment in the renderer process can become vulnerable to XSS attacks wherein the attacker can load javascript and execute code on the user's computer. The current methodology limits the usage of Node APIs in the renderer process eventually avoiding such attacks. A detailed read regarding the same can be found in official Electron's documentation.

However, before proceeding with the actual implementation, the bundling pipeline had to refactored by removing the Parcel bundler and migrating it to Webpack. This is because Parcel requires the Node environment to be present in the the renderer process while bundling any Electron application due to it's HMR configuration. The Parcel team is currently working in order to provide better support for Electron applications and the entire proposed improvements can be found here.

The entire project tasks/sub-tasks can be found listed here - electron/fiddle#1100

Quickly listing down sub tasks -

1 - Migrating away from Parcel bundler
2 - Moving ipcRendererManager to preload scripts
3 - Integrating fiddle-core
4 - Refactoring Node calls to IPC events



Previously, Fiddle used Parcel to bundle all of it's file including the main and the renderer process. However, as the project scope demanded the removal of it, the bundling process was refactored to use the webpack plugin along with Electron forge (@electron-forge/plugin-webpack)

The current bundling architecture maintains webpack.main.config and webpack.renderer.config to bundle code for main and renderer process respectively. This outputs to bundle all files in .weppack folder which includes -

  • main- The bundled main process code.
  • renderer- The bundled renderer process code.
  • static- Includes code templates used by fiddle (show-me templates and electron-quick-start code)
  • assets- All images/icons present in the project.


With the current architecture, the preload script exposes the following type of APIs to the renderer process -

  • IPC: Previously, the renderer process would directly invoke the ipcRenderer API for it to communicate with the main process. Now, due to the absence of Node environment, the ipcRenderer API is handled in the preload scripts and the channels are safely exposed to the renderer process via the contextBridge API.

  • Electron/Node APIs: There are few commonly used Electron and Node APIs present in the React components (clipboard,platform) These can be migrated to use the IPC channels but it unnecessarily complicates the task as their complexity is low. Hence, these can be directly initialized in the preload scripts so that the renderer process can fetch it using the window object. For instance - window.platform will directly return the platform the user is on.

The below diagram explains it better ("A picture is worth a thousand words!") -



Here's a detailed list of all the contributions made across fiddle and fiddle-core -


Related to proposed ideas

#1109: build(forge): introduce webpack plugin and remove parcel (resolves #1)
#1134: refactor: integrate fiddle-core (resolves #3)


#1138: build(webpack): remove webpack definePlugin pointing to static folder
#1144: refactor: remove dead code
#1147: build: enforce sort-imports eslint rule
#1115: fix: disable right click contextMenu in settings page
#1160: build(deps): upgrade to blueprintjs@4

Yet to be completed

#1114: feat: migrate IPCRendererManager to preload scripts


#26: refactor: add default parameter for Runner.create
#27: docs: fix minor variable typo in example
#28: refactor: properly handle removal of electron version
#29: docs: fix the given API usage example
#31: feat: add installing options for electron binary
#33: refactor: modify InstallState to be an enum
#34: ci: install dependencies with --frozen-lockfile flag
#35: feat: allow installing of multiple version simultaneously
#36: build(deps): upgrade @electron/get
#37: feat: allow usage of already unzipped electron versions

Issues faced

Probably, it was debugging wherein I spend most of my time as compared to actually coding it!

There were quite some blockers that I faced right after starting out with the project. This was probably because I was working in depth with webpack and integrating it to such a large codebase for the first time. (Special thanks to David for helping me out with them!)

The major blocker was with the monaco-editor web workers unable to access Node __dirname API in production build of fiddle. This github gist explains the blocker in much elaborative way. After collectively debugging into the issue, turns out that html-webpack-plugin doesn't has the support for __dirname due to which we have to forcefully monkey-patch Electron forge for it to function properly (Thanks to Keeley for pointing it out and assisting me in debugging).

What's left ?

Woefully, migrating Node APIs from the renderer process to main process (#4) is still a blocker due to above listed issue (regarding the lack of __dirname in html-webpack-plugin) The pull request jantimon/html-webpack-plugin#1650 is to be reopened and worked upon again for it to resolve.

Once, the support for __dirname is accepted by the html-webpack-plugin maintainers, we can refactor Electron forge to remove the unnecessary code and finally this should do the job :)

Closing remarks

Thanks for having me as a GSoC student and to closely work with the Electron team. I am thankful to my mentors for their advices, code reviews, resolving my queries regarding few parts of codebase, the design approach and so.

The last couple of months were really productive, gaining a massive experience as developer and learning about Electron architecture in depth. Over these past few months I have improved myself in programming skills, especially the art of writing clean code :)

Post GSoC

Though the GSoC "coding phase" has ended, I will still be unofficially working closely with the Electron team to complete the last part of my proposed plan i.e to move all the Node APIs from the renderer process to the main process (related pull request) Apart from this, I will look forward to reviewing code and working on other Electron projects as well :)

Copy link

please guide me bro i am new on gsoc and github

Copy link

Hey Aryan I'm Interested to Work on This code base. Please point me to the main github branch.

Copy link

Hi, Aryan I am very interested in working on this project can you please navigate me to the main GitHub branch...
-Devesh Sharma

Copy link

hey ,I am Daya ,I want to work on this project can you point me to the original branch or the repo i am new to open source

Copy link

hello, my name is Kashif Rezwi. I'm new to open source and very interested to work with new people please guide me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment