splitKeyPath undefined

[McPo]

It appears that there is an issue with one of the libraries used within this project. I submitted a PR regarding this to the upstream project but they don't seem that responsive.

Would you be willing to change the key-path-helper dependency to the git url of my pull request until they merge it in.

atom/key-path-helpers#2

Thanks,
Emmet

(Im surprise no one else is running into this though)

[nathanbuchar]

Yeah, I don't know if this is an issue with their library, or possibly electron-settings is passing in an undefined value to be split which is causing the error. I'm still trying to track it down be have not yet been able to reproduce the error. Are you compiling your code in any way? Methinks it may have something to do with hoisting because the splitKeyPath function is used before it's defined; This shouldn't matter when used normally because function definitions are hoisted automatically in JavaScript, but maybe a compiler is messing with it in some way

See #33

[nathanbuchar]

If you could show me your electron-settings debug output, that would be extremely helpful.

Ensure you are using the latest version of electron-settings (v2.2) and enter this into your terminal export DEBUG="electron-settings:*" then start your Electron app (from the same Terminal window).

The output should look something like this:

> electron app

  electron-settings:main observing settings file +0ms
  electron-settings:main global configuration set to {"atomicSaving":true,"prettify":true,"settingsDir":"/Users/nathan.buchar/Library/Application Support/Your App","settingsFileName":"Settings","overwrite":false} +230ms
  electron-settings:main defaults set to {"isSubscribedToAll":true,"subscriptions":["all"]} +3ms
  electron-settings:main called applyDefaultsSync() +0ms
  electron-settings:main ensuring settings file... +0ms
  electron-settings:main reading settings... +0ms
  electron-settings:main writing settings file... +2ms
  electron-settings:main settings file observer reset +3ms
  electron-settings:main observing settings file +0ms
  electron-settings:main called setSync() at "version" +0ms
  electron-settings:main ensuring settings file... +0ms
  electron-settings:main reading settings... +1ms
  electron-settings:main writing settings file... +0ms
  electron-settings:main settings file observer reset +1ms
  electron-settings:main observing settings file +0ms
  electron-settings:main called setSync() at "lastOpened" +0ms
  electron-settings:main ensuring settings file... +0ms
  electron-settings:main reading settings... +0ms
  electron-settings:main writing settings file... +0ms
  electron-settings:main settings file observer reset +0ms
  electron-settings:main observing settings file +0ms
  electron-settings:main detected change to settings file +294ms
  electron-settings:main detected change to settings file +2s

[JohnnyCrazy]

@nathanbuchar
This is definetly an issue with their library, applying @McPo's fix works, but sadly didn't get merged yet. (Already a month old)

Since you can't reproduce this, are you transpiling your node_modules? It's very weird because the error pretty much happens in any case when installing this lib.

Would you mind changing your key-path-helper-dependency to his PR-Url for the time the PR isn't merged like @McPo suggested? Would prevent everyone rolling out there own fixed versions.

[nathanbuchar]

@JohnnyCrazy perhaps you're running an older version of Node/Electron that does not support newer syntax. What version of Electron are you running your applications with?

[JohnnyCrazy]

@nathanbuchar Everything is up-to-date, electron 1.3.5, node 6.5.0.

I just checked with a simple electron-getting-started-app, and it seems to work there. My guess, I'm using WebPack to serve the files, and it seems like it's not served the same way electron would (It's sending the JS-Files over the line using a local running web-server). But since it's working with the default setup, guess there is nothing to be changed, sorry for the inconvenience

[McPo]

It looks like this may be related to transpliing #38 .
Ive added some more notes to that issue as to how to obtain a transpiled version.

I think this issue can be closed now.

[nathanbuchar]

Closing in lieu of #38