@matheuss I think it depends on how next export it's going to work, if it's going to only generate static html files without client-side getInitialProps then it's not going to be useful for this use case 🤔 also you will need to re-export your app after every change

BTW, what kind of security vulnerabilities do you thinks can this introduce?

good idea, share some pages with some friends.

@sergiodxa I think @matheuss is concerned potentially about browsers probing localhost, finding the port, then finding open routes? Maybe an advisory in the README about that vector would be good

next export will certainly output 100% static stuff. So, if you only limit yourself to serving static stuff via Next, there shouldn't be any security issues. Protecting POST stuff is the key, and not performing side effects upon GET

In browsers the client code breaks (because Webpack doesn't do anything to the require function), you only get the server rendered page. Anyway I added an warning in the README about the possible access from a browser.

I also added a little validation code to respond with 404 if the request does not come from an Electron app. It's not fully secure but it should hide, for unintentional users, the access to the app from a browser.

@sergiodxa can you look into whether a unix socket file would be a viable option?

https://nodejs.org/api/net.html#net_server_listen_path_backlog_callback

Now Desktop is another example now.

@rauchg I have tried to use a Unix Socket with the net module but Next require an request and response object, I'm not use if it's possible : thinking:

@leo yeah! I just checked the code and the server it's basically the same, awesome, I also published yesterday a Spanish tutorial about this example. Using Next inside Electron to avoid configuration it's pure magic.

Please wait with this. I'll release a blog post about this very soon (describes how to use Next.js with Electron in detail)... 😊

@sergiodxa Have you tested by creating a package ? I created a darwin build and it didn't launch.

We're using it here. Feel free to test!

@ritz078 Yes, I tested it using this example, are you having any error in console?

No there isn't any error in the console.

I cloned the same and added electron-packager

{
  "scripts": {
    "dev": "electron index.js",
    "build": "next build",
    "start": "NODE_ENV=production electron index.js",
    "pack": "electron-packager . --out=package --darwin --overwrite"
  },
  "dependencies": {
    "electron": "1.6.2",
    "next": "^2.0.0-beta",
    "react": "^15.4.2",
    "react-dom": "^15.4.2"
  },
  "devDependencies": {
    "electron-packager": "^8.6.0"
  }
}

The app is being created fine npm run pack but its not launching the window.

It seems this is the error.

// written here executes
nextApp
  .prepare()
  .then(() => {
// anything written here doesn't execute after packaging
})

@sergiodxa I have figured it out with a help of a custom Electron protocol: https://electron.atom.io/docs/api/protocol/#protocol

I am testing it right now and will create a PR.

@sergiodxa For some really weird reason, I cannot create a PR against your fork. Please, pull my commit: frol@e44c97c

By the way, you cannot use cookies for "current domain" when your page is open as file://. I have experimented with using the custom next:// protocol, but it doesn't play nicely as well. I may simply use other means for the storage as cookies don't make a lot of sense in a standalone app, but it just has different behavior from the dev mode, so it is better to be prepared.

P.S. I have a biggish app in Next.js, and I am just stressing this Electron example with it.

I have found a workaround for the cookies in Electron, just use @expo/electron-cookies. Here is a snippet which you need to put somewhere in the top-component (_document.js or common high-level component):

if (typeof document !== 'undefined') {
  const ElectronCookies = require('@exponent/electron-cookies')
  ElectronCookies.enable({
    origin: 'https://example.com',
  });
}

So far, I have managed to package my whole Next.js application into Electron and it is fully functioning! I had to only workaround the superagent/node-formidable issue, the missing cookies support and files upload implementation (I had to use fs.createReadStream() instead of plain File objects when POSTing them).

@sergiodxa Thank you for the example!

@leo Any updates on the blog post? I'm looking forward to it :) Thank you for the examples so far.

@trevordmiller Coming very soon - sadly can't tell anything else publicly. But it's VERY close!

@sergiodxa Thank you for the updated example! It is really easy to get any Next.js project packaged into Electron now!

@leo what's the status of this one? 😄 Wearing my project manager 🎩... 😂

I'm also waiting for this to introduce to our devs as an organizer of Electron meetup in Korea and a big fan of next.js

My helper package is already out! Blog post very close... 🚀

@leo cool 👍 🤗 🚀

Just published my blog post about building Electron apps using Next.js and created a boilerplate. If it looks good to you, I suggest basing this PR on it! 🚀 ❤️

Thanks @leo 🎉

I updated this example to bring some ideas of electron-next-skeleton, now it's simpler, but I keep the UI so the example show how you can import Electron modules in the renderer process and use IPC between the Next.js (renderer) app and the main process.

cc @leo @timneutkens