Transpiling to ES5

[JohnnyCrazy]

Hi,

It would be nice if this library would be transpiled to ES5 (in a folder like /dist) using something like babel before getting pushed to git/NPM.
It's not standard to require the user to transpile stuff installed to node_modules, and without transpiling, it could raise some errors when trying to use this code with specific webpack/grunt/gulp plugins.

My use-case
I'm using this together with vue-electron and webpack. When webpack is building the app for production use, it uglifies everything inside node_modules. Sadly, it doesn't have support for ES6, so your library will raise an error and the build fails. I could add exclude the library, but I guess it would be better to fix it at the root.

[nathanbuchar]

Hey @JohnnyCrazy,

Thanks for trying Electron-Settings! However, Node 6 and up is almost entirely ES6 compliant; This module is specifically built for Electron, and if the transpiler you're using does not support the base technology that Electron is built on then there's probably something wrong with using the transpiler.

Forgive me if I'm wrong, but isn't Webpack designed to only be used for front-end web? Using Webpack with Node and Electron seems overzealous and backwards to me, but I don't have much experience with Webpack. Additionally, isn't it common practice to "skip" node_modules when compiling code with a compressor like Webpack or Browserify? Why is that not possible here?

[JohnnyCrazy]

While it's true Node 6 supports it, this is more like following a specific standard. Looking at the list of electron tools, everyone of them uses some kind of transpiler to ensure compatibility. However, I'm just a single user out of 100s. So no problem if you don't want to go that way, I will just have to figure out another way :)

Well, what do you mostly do when developing with electron? front-end web stuff. electron-vue is using Webpack for multiple features, like hot-reloading, scss/sass compiling, es6-babel and this one feature which is interfering right now: It's optimizing and minifying node_modules for the packager. This works with about 80 packages, but sadly not with yours. And on top of that, the exclude-option of this optimizer and minifier sadly only applies post-processing (Which is kinda weird...).

[McPo]

I too am using webpack, as @nathanbuchar stated Im doubtful with regards to what purpose it serves in an electron application (I originally forked my project from electron-react-boilerplate which was setup to use webpack, and honestly its been a bane).

Just add the following line to your package.json to use my transpiled version

"electron-settings": "McPo/electron-settings#transpiled",

Building the project should work on OSX and Linux, you may have issues on Windows. After making the initial required changes I started to run into issues regarding having to many files open. This was due to babel being processed twice. In order to correct this I used the https://www.npmjs.com/package/postinstall-build package to build the library and then remove the unnecessary dependencies. Then I ran into an issue with webpack re-running the installation after copying the library to a distribution folder, but the files execution permission of the postinstall-build script wasn't retained and would error out. As such I had to test whether the folder existed first, if it did, I didn't re-building it. The 'test' command is only available on OSX and Windows.

I could've re-published the transpiled version, but then 2 versions of electron-settings would be on npmjs, and Id rather avoid that.

I think this issue can be closed now.

[nathanbuchar]

Thanks for the info! I'd be willing to try to find a common solution. The problem lies with the Atom key-path-helpers package, is that correct? In electron-settings v1—before key-path-helpers existed as a standalone module—I rewrote them locally and never had any issues regarding transpiling. I'd be fine with pulling them into a local file and do a little re-writing if that solves the problem, just need to know that that is indeed the issue here :)

[McPo]

Yeah in order to resolve the issue key-path-helpers and electron-settings would need to be transpiled. The easiest way would be to have a local copy of key-path-helpers and then just transpile electron-settings (Its straight forward to do).

I was originally gonna suggest you do that, however considering the electron team doesn't feel the need to transpile key-path-helpers, it shouldn't fall on you to do so. It also means that other libraries provided by the electron team will need the same treatment. However if you want to expand the libraries userbase, it might be a wise choice. Its not as if key-path-helpers changes often, or transpilation is difficult to do.

If you need me to test anything let me know. On the off chance you haven't transpiled anything before, this guide is pretty decent https://booker.codes/how-to-build-and-publish-es6-npm-modules-today-with-babel/

[andrewjaykeller]

Any progress on this? Can't use import settings from 'electron-settings' or const settings = require('electron-settings')

Using https://github.com/chentsulin/electron-react-boilerplate so very easy to duplicate the problem @nathanbuchar

[andrewjaykeller]

Do you think this error:

ERROR in bundle.js from UglifyJs
SyntaxError: Unexpected token: name (Observer) [./app/~/electron-settings/lib/observ
er.js:7,0]

is from electron-settings not being transpiled.

[McPo]

In the end I came across a few other projects that hadn't been transpiled before publishing, and their maintainers were less than helpful (Were adamant they shouldn't have to transpile before publishing, despite it being recommended by npm)

So I needn't to come up with a solution to sort all the projects at once.

Within webpack.base.config you'll notice that Babel is stated to ignore this node_modules folder. What you want is to add another loader which specifies specific projects within node_modules that also need transpiled.

Something like this.

{
                test: [/node_modules[\\\/](?:boom|hawk|hoek|cryptiles|sntp|enfs(?:.+))[\\\/]lib[\\\/](?:.+).js/],
                loaders: ['babel-loader']
            },
            {
                test: /\.jsx?$/,
                loaders: ['babel-loader'],
                exclude: /node_modules/
            },

You'll notice in the top loader a list of projects separated by |, you'll need to modify the list to match your own project. Start by removing all other name and adding electron-settings to the list.

On mobile, so if nothing's clear let me know and I'll clarify when I'm near my laptop again.

[andrewjaykeller]

@McPo are you saying that npm package publishers should be transposing down to ES5 before npm publish? I make a module and am not doing that!!

[McPo]

@aj-ptw Im not sure whether "am not doing that!!" was meant as "Im not doing it and I don't intend on doing that!", or "Im not doing that, should I be doing that?".

Also to clarify the post I made above was supposed to be in response to you, so that should (hopefully) resolve your issue. (If it doesn't, upload your webpack config files so I can take a look)

If your wondering why I stated that transpiling down to ES5 is the 'done' thing. Well babel by default ignores node_modules. So you can assume that if you want your plugin to 'just work', you should be transpiling before hand.

You may think theres a few instances were this isn't necessary, such as in this project, were its directly targeting a known browser which supports all the required features. The problem is other tools used in the pipeline may not support ES6 ie UglifyJS. So it can still be useful to transpile before.

However the projects I was talking about where actually targeting the open web (In which case I believe they really ought to be transpiling before publishing, otherwise all your users will need to transpile it), I think the maintainers of some of the projects went a bit 'diva' on the suggestion. They took the approach that all browsers should just step up and support ES6, and everyone should be using said browsers (In a perfect worlds thats fine, but this isn't a perfect world), as opposed to them taking a minute or two to setup transpiling before publishing. They never actual gave a sound reason against, just immediately dismissed the prospect.

[andrewjaykeller]

@McPo it was for sure "Im not doing that, should I be doing that?" haha

I guess my module, openbci, is meant to be run on the backend.

I'm still getting pretty errors this repo though...

When I include electron-settings in externals I get:

app.html#/welcome:1 Uncaught (in promise) Error: ENOENT: no such file or directory, rename '/Users/andrewkeller/Library/Application Support/Electron/Settings-tmp' -> '/Users/andrewkeller/Library/Application Support/Electron/Settings'(…)

When I remove from externals and do as you instructed:

{
      test: [/node_modules[\\\/](?:electron-settings(?:.+))[\\\/]lib[\\\/](?:.+).js/],
      loaders: ['babel-loader']
},

I get the error "splitKeyPath is not defined" when i try to set a setting.

[McPo]

try

Option 1:

{
      test: [/node_modules[\\\/](?:electron-settings|key-path-helpers)[\\\/]lib[\\\/](?:.+).js/],
      loaders: ['babel-loader']
},

Option 2:

If that fails to work, change electron-settings in your package.json to

"electron-settings": "McPo/electron-settings#release-dist"

This is my fork which includes electron-settings pre-transpiled and a patch to one of its dependencies. (It also has encryption, although if you don't set a key, it won't affect you). Its also a bit older than master (I think its missing the ability to set the Settings filename path, which is what the latest electron-settings allows you to do).

More info on the key-path-helpers issue here atom/key-path-helpers#2 (review)

Option 3

Use the latest electron-settings but my patched key-path-helpers. (In package.json)

"electron-settings": "2.2.2",
"key-path-helpers": "McPo/key-path-helpers#splitKeyPath-fix"

[patleeman]

Option 1 worked perfectly for my project. I'm using electron-vue boilerplate as well and this solved the problem.