Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create macos installer #20

Merged
merged 27 commits into from Jun 29, 2017
Merged

Create macos installer #20

merged 27 commits into from Jun 29, 2017

Conversation

dereklieu
Copy link
Collaborator

I finally got the mac os packager and installer working.

This also does some extensive re-organizing to make native module handling more straightforward.

  • Moves all electron files, including the compiled dist, into src.
  • Includes a second package.json in src and moves .npmrc into src as well.

Reason: I was running into issues because appdmg requires native modules that were getting built for electron thanks to the presence .npmrc. Now, all the electron modules should go into the secondary package.json file, while development modules live in the root package.json.

This does lead to some directory weirdness, like the fact that dist now gets built and put in src. I don't think this is a huge deal though.

Also, a note that when requiring electron in the render thread, you must use window.require('electron').

@dereklieu dereklieu requested a review from mojodna June 29, 2017 17:47
@@ -1,16 +1,18 @@
{
"name": "field-data-coordinator",
"productName": "Field Data Coordinator",
"productName": "observe-desktop",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is supposedly the string that's used in the application menu.

@mojodna
Copy link
Contributor

mojodna commented Jun 29, 2017

Awesome.

Reason: I was running into issues because appdmg requires native modules that were getting built for electron thanks to the presence .npmrc. Now, all the electron modules should go into the secondary package.json file, while development modules live in the root package.json.

So src is effectively the application code and everything above that is build-related? That makes sense, but maybe app is a better name for src?

Can you elaborate on the appdmg native module requirement? I don't follow what the underlying problem is. Is it trying to rebuild for the electron runtime itself?

This does lead to some directory weirdness, like the fact that dist now gets built and put in src. I don't think this is a huge deal though.

Would a slightly less weird equivalent be copying src/package.json into dist/ instead?

Also, a note that when requiring electron in the render thread, you must use window.require('electron').

What's the underlying reason for this? (Mainly curious.) Is it because electron isn't actually a dep in src/package.json?

Copy link
Contributor

@mojodna mojodna left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it works, 👍!

I'm definitely curious about some of the whys, but running code is fantastic.

@dereklieu
Copy link
Collaborator Author

I think the renaming to app makes a lot of sense.

On appdmg, my theory is that the presence of .npmrc in the root directory was causing yarn to download the version for electron node rather than system node.

Would a slightly less weird equivalent be copying src/package.json into dist/ instead?

Thinking about this more, the right way to do this is probably to copy both main.js and package.json into dist. 👍

Last, on window.require, it's to do with electron bundling a commonjs environment, which allows you to require things at runtime rather than compilation. This is the issue I found on it.

I'm actually glad you pointed that out, since lib/surveys lives on the main thread and not the renderer, it doesn't need window.require. Going to remove that.

@mojodna
Copy link
Contributor

mojodna commented Jun 29, 2017

On appdmg, my theory is that the presence of .npmrc in the root directory was causing yarn to download the version for electron node rather than system node.

Yup, that makes total sense. And/or build against the electron runtime. The "correct" fix is probably to make electron-rebuild pass appropriate options to node-pre-gyp so that it will download packaged binaries vs. trying to recompile. Meanwhile, this makes sense.

Thinking about this more, the right way to do this is probably to copy both main.js and package.json into dist. 👍

Just main.js or it and everything it requires? dist/ is just the code that runs on the rendering thread, yes?

Last, on window.require, it's to do with electron bundling a commonjs environment, which allows you to require things at runtime rather than compilation. This is the issue I found on it.

Awesome. Makes sense. Thanks!

@dereklieu
Copy link
Collaborator Author

@mojodna I ended up copying over everything that main.js requires as well. I think it's a marginally better solution than what I had before, with the caveat that adding another dependency to main.js will mean needing to add a line in the gulpfile (unless it's in a folder that's already getting copied over, like lib). So now dist contains everything needed for the electron app.

@dereklieu dereklieu merged commit 3c71d4a into master Jun 29, 2017
@dereklieu dereklieu deleted the package branch June 29, 2017 19:50
@mojodna
Copy link
Contributor

mojodna commented Jun 29, 2017

unless it's in a folder that's already getting copied over, like lib

Maybe we should structure so that libs for the main thread live in ..., libs for the renderer in ..., and shared ones in shared or something. Then we won't need to deal with the hassle of updating the Gulpfile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants