Upgrade ember-cli-babel & ember-runtime-enumerable-includes-polyfill to remove deprecation warning

[jacobq]

The current release (1.0.0) triggers an annoying deprecation warning with recent versions of Ember, which would be fixed by upgrading to the latest releases of ember-cli-babel (6.11.x) and ember-runtime-enumerable-includes-polyfill (2.1.0). Please consider updating these.

├─┬ ember-localstorage-adapter@1.0.0
│ ├─┬ ember-cli-babel@5.2.4
│ │ └── ember-cli-version-checker@1.3.1 
│ └─┬ ember-runtime-enumerable-includes-polyfill@1.0.4
│   └── ember-cli-version-checker@1.3.1 

The deprecation warning looks like this and is described here:

DEPRECATION: An addon is trying to access project.nodeModulesPath. This is not a reliable way to discover npm modules. Instead, consider doing: require("resolve").sync(something, { basedir: project.root }). Accessed from:   new NPMDependencyVersionChecker (/path/to/project/node_modules/ember-getowner-polyfill/node_modules/ember-cli-version-checker/src/npm-dependency-version-checker.js:11:33)

[joestein216]

@jacobq tried creating a pull request for this, had to update a few things to get tests to pass locally, but failed in travis due to PhantomJS issues. What about trying to update to ember 2.16 LTS and start from there?

Here's the pull request that failed, I figured I'd try this small change and see if it can pass:

222

@locks, what do you think about me trying again from an update to ember 2.16?

[jacobq]

FWIW, I was recently working on a simple addon (just added a single helper) and found it much easier to create a fresh addon and migrate the actual addon & test code than to try to upgrade all the dependencies and get the addon boilerplate to match the latest. I think that strategy might still work well for a more complex addon as well.

I also wouldn't mind waiting a little longer if it meant updating to an ember-cli version that doesn't rely on bower at all. (Looks like this is the case in 3.0.0-beta.2.

Update: For those who may stumble upon this later, check out ember-cli-update instead!

[joestein216]

@jacobq not sure what your needs are, but I was trying this as-is for a new requirement for one part of an app that just needed to persist to localstorage, but I wanted to model it with relationships to other already integrated models in the app...

The adapter and serializer provided by:

https://github.com/funkensturm/ember-local-storage

Worked great with just changing the adapter and serializer files.

Still willing to try to update this addon if it will benefit folks...

[jacobq]

@joestein216 thanks for the comment. I am using ember-localstorage-adapter as the entire persistence layer of an electron application; that's where all of the data is being saved to / loaded from. If I absolutely have to then I will switch to something else, but for now it is working, and I'm hoping that this will be maintained so no change is needed. (Seems like I spend a lot of time dealing with "distractions" / dependencies / boilerplate rather than my actual app.)

Any idea why there is more than one implementation of what seems like "the same thing" here? In other words, how should someone choose between ember-localstorage-adapter and ember-local-storage?

[locks]

Thanks for the discussion everyone, I'll look into it soon!

[jacobq]

@locks, any chance you'll have time to look at this again soon? With the latest ember-cli release (I'm using 3.1.3) there seem to now be louder warnings, e.g.:

DEPRECATION: ember-cli-babel 5.x has been deprecated. Please upgrade to at least ember-cli-babel 6.6. Version 5.2.8 located: my-app -> ember-localstorage-adapter -> ember-cli-babel