Electron Remote: To Bundle Or Not To Bundle In Pulsar?

Hey guys, let's dive into a fascinating discussion about how Pulsar handles the @electron/remote package. Previously, packages could simply use const { remote } = require('electron'); and it would just work. This was due to some clever short-circuiting in Electron's module resolution, effectively treating electron like a built-in Node module.

However, with Electron 13, require('electron').remote has been deprecated, and its functionality has moved to the @electron/remote package. Unlike the old method, this new package requires explicit installation as a dependency for third-party Pulsar packages. Now, this is where things get interesting, and where we have a decision to make as a community.

The Dilemma: @electron/remote and Pulsar Packages

Pulsar itself depends on @electron/remote, which allows it to shim older references to require('electron').remote and provide deprecation messages to encourage package authors to update their imports. This creates a bit of a conundrum: is it better to treat @electron/remote as a regular package, or should Pulsar handle it magically to ensure compatibility and reduce redundancy?

Let's explore the arguments for each side.

Argument for Treating @electron/remote as a Regular Package

Think of @electron/remote as that quirky relative everyone tolerates but doesn't quite understand. The argument here is that @electron/remote is a discouraged hack by the Electron team, evident by its removal from the core electron module. By treating it as a regular package, we discourage its use and push developers towards more modern, recommended approaches. This aligns with the principle of using best practices and avoiding deprecated features.

If we follow this path, it's crucial to identify the common use cases for @electron/remote and develop preferred APIs for those scenarios. Currently, several built-in Pulsar packages rely on @electron/remote, so cleaning up our own codebase would set a good example. This involves refactoring these packages to use alternative methods that don't depend on @electron/remote. This proactive approach ensures that our core packages are aligned with the latest Electron recommendations and promotes a more maintainable codebase.

Furthermore, treating @electron/remote as a regular package fosters better dependency management. When a package explicitly declares @electron/remote as a dependency, it becomes clear which packages rely on this functionality. This transparency helps developers understand the dependencies of their projects and manage them accordingly. It also simplifies the process of updating dependencies, as each package is responsible for managing its own version of @electron/remote.

However, this approach also requires more effort from package authors. They need to explicitly install @electron/remote as a dependency and update their code to use the new package. This can be a time-consuming process, especially for large projects with numerous dependencies. Additionally, it can lead to version conflicts if different packages rely on different versions of @electron/remote. Therefore, it's essential to provide clear guidelines and documentation to help package authors navigate these challenges and ensure a smooth transition.

In summary, treating @electron/remote as a regular package aligns with the principles of using best practices, fostering better dependency management, and promoting a more maintainable codebase. However, it also requires more effort from package authors and can lead to version conflicts if not managed carefully. Therefore, it's essential to weigh the pros and cons carefully before making a decision.

Argument Against: The Magic Approach

Alternatively, imagine @electron/remote as that one tool everyone needs, but nobody wants to buy separately. The argument against treating @electron/remote as a regular package stems from the idea that if package authors are inevitably going to use it, they might as well use the version that Pulsar already includes. This ensures compatibility with the current Electron version and avoids potential conflicts arising from different packages using different versions of @electron/remote.

Therefore, we could actively discourage developers from installing their own version and instead treat imports of @electron/remote magically, similar to how electron itself is handled. This could be achieved by injecting logic into Pulsar's module resolution algorithm to detect imports of @electron/remote and redirect them to Pulsar's own module path. This approach would provide a seamless experience for package authors, as they wouldn't need to worry about installing and managing @electron/remote as a dependency.

To mitigate the potential drawbacks of this approach, we could offer up Pulsar's copy of @electron/remote only if the resolution would otherwise fail. This would allow packages that have explicitly installed @electron/remote as a dependency to use their own version, while still providing a fallback for packages that haven't. This hybrid approach would combine the benefits of both methods, ensuring compatibility while still allowing for flexibility.

Moreover, this magic approach can reduce the overall size of Pulsar packages. By eliminating the need for each package to include its own copy of @electron/remote, we can significantly reduce the total number of dependencies and the overall size of the packages. This can improve the performance of Pulsar and reduce the time it takes to install and load packages.

However, this approach also has some potential drawbacks. It can make it harder to track which packages are using @electron/remote and can create unexpected behavior if a package relies on a specific version of @electron/remote that is different from the one provided by Pulsar. Additionally, it can make it harder to update @electron/remote in the future, as we need to ensure that all packages that rely on it are compatible with the new version.

In conclusion, treating @electron/remote magically can ensure compatibility, reduce redundancy, and improve the overall size of Pulsar packages. However, it can also make it harder to track dependencies, create unexpected behavior, and complicate future updates. Therefore, it's essential to weigh the pros and cons carefully before making a decision.

The Chaotic Neutral Option: Let It Be

Think of this option as embracing the chaos – sometimes, the easiest path is the one already paved, even if it's a bit bumpy. We could simply allow developers to continue using require('electron').remote. Since it's already working (accidentally), it might be the simplest solution in the short term. To avoid confusing developers with deprecation messages, we could remove the deprecation notice while we evaluate the other options. Now, I'm not saying this is the best idea, but it's a viable option that deserves consideration.

This approach has the advantage of requiring minimal effort in the short term. We wouldn't need to make any changes to Pulsar's module resolution algorithm or update any existing packages. This would allow us to focus on other priorities while still providing a working solution for developers who need to use @electron/remote.

However, this approach also has some significant drawbacks. It perpetuates the use of a deprecated feature and doesn't address the underlying issue of managing @electron/remote as a dependency. It also relies on an accidental behavior that could be subject to change in future versions of Electron. Therefore, it's not a sustainable solution in the long term.

Furthermore, this approach can create confusion for developers who are new to Pulsar. They may not understand why require('electron').remote is working and may not be aware of the recommended alternative of using the @electron/remote package directly. This can lead to inconsistencies in code style and make it harder to maintain packages in the long run.

In summary, allowing developers to continue using require('electron').remote is a viable option in the short term, but it's not a sustainable solution in the long term. It perpetuates the use of a deprecated feature, doesn't address the underlying issue of dependency management, and can create confusion for developers. Therefore, it's essential to carefully consider the pros and cons before making a decision.

The Path Forward: A Community Decision

So, what do you guys think? Should we embrace the magic, enforce the rules, or just let things be for now? Each option has its merits and drawbacks, and the best path forward depends on our priorities as a community. Let's discuss and decide how we want to handle @electron/remote in Pulsar.