Feathers-vuex: Cannot read property '_' of undefined

[adrianofoschi]

Steps to reproduce

I upgraded my application to feathers 4.3.0.
I guessed that I need to update feathers-vuex to 2.0 to support featherjs/authentication-client 4.3.0.

Expected behavior

I tried to add feathers-vuex 2.0 to my QuasarJS project but I have a syntax error.

Actual behavior

Uncaught TypeError: Cannot destructure property `_` of 'undefined' or 'null'.
    at eval (service-module.getters.js?403b:12)
    at Module../node_modules/feathers-vuex/dist/service-module/service-module.getters.js (app.js:5005)

the line is
const { _ } = commons

Module Loader:
Webpack

[adrianofoschi]

Note: the same error now with version 1.7.0

[adrianofoschi]

I solved replacing in service-modules.getters.js

import commons from '@feathersjs/commons'
const _ = commons;

with

import { _ } from '@feathersjs/commons'

[marshallswain]

I've released [email protected] with the import fixed. Please let me know how it goes.

[adrianofoschi]

It works.
Thanks you.

[MichaelJCole]

@marshallswain @adrianofoschi is there a fix/workaround that doesn't require upgrading to 2.0?

[marshallswain]

@MichaelJCole yes. A PR with the edit described in this commit: https://github.com/feathers-plus/feathers-vuex/issues/247#issuecomment-525827334

[MichaelJCole]

Sure, funny. I'm writing up an article about a starter project I put together integrating Quasar and Feathers with FeathersVuex, and I can't recommend using your package - it's unreliable, undocumented, and all over the place.

Luckily, I found a yarn.lock file in git.

[marshallswain]

@MichaelJCole What is your intention with telling me that you can't recommend my package?

[marshallswain]

@MichaelJCole this bug was brought on by a breaking change in another package. I have time to maintain 2.0, which is production ready if you follow the instructions and will save you so much time. If you want 1.0 to work for you, please submit that one-line PR that I recommended and I will gladly accept and release. I don't work for free for things that I do not require for myself. I am gladly sharing 2.0, in all of its awesomeness, with the community, for free, because it supports me. I have no contract with anybody, including myself, to support v1.0, so your desires will need to be supported by you. I'll gladly assist you in supporting yourself. :)

[adrianofoschi]

@MichaelJCole I am using latest version of feathers, feathers-vuex and QuasarJs, all work perfectly. You should simply read this:

https://github.com/feathers-plus/feathers-vuex/pull/216

We are waiting for the official documentation updated according with version 2.0.
Finally you can wait for It or alternatively you should contribute :)

[dkebler]

@adrianofoschi I am using quasar as well. I assume that since quasar doesn't have a vue.config.js that the transpile property should be an added key/prop in quasar.conf.js?

transpileDependencies: ['feathers-vuex']

update: looks like that goes within the build key

[MichaelJCole]

Hi @dkebler I put together a starter project/prototype using feathers-vuex.

If you're interested, this file is a good place to start reading how I did it.

https://github.com/MichaelJCole/Quathers/blob/master/src/boot/feathers.js

There may be better ways :-)

[dkebler]

I'll take a look but I've been using quasar and feathers-vuex in a production build since April. Only yesterday when I went back to work on updating everything (quasar, featherjs, etc) have I run into this issue. Despite what @marshallswain noted using feathersjs4 and fv 2pre77 with the transpile key now at least gives me a warning but the issue persists.

So despite being "fixed" this issue remains for me with 2pre77

after adding transpile property I get

 warning  in ./src/store/index.js

"export 'default' (imported as 'feathersVuex') was not found in 'feathers-vuex'

as I root around I see @marshallswain

1. f-v 2pre77 lists "@feathersjs/errors": "^3.3.6", but feathersjs4 loads errors 4
2. STILL! f-v 2 pre 77 is loading a default commons

import sift from 'sift'
import commons from '@feathersjs/commons'
import dbCommons from '@feathersjs/adapter-commons'
import { omit as _omit } from 'lodash'

const { _ } = commons

which should according to @adrianofoschi should be

import {_} from '@feathersjs/commons'

here is the transpiled ts loading the default
var commons_1 = __importDefault(require('@feathersjs/commons'))

Bottom line...I am stuck. After becoming totally dependent on f-v now I can't get 1.7 or 2.0 to honor the commons dependency from feathersjs 3 or 4.

[morphatic]

To make the warnings go away, try adding sourceType: 'unambiguous' to your babel.config.js file. Mine looks like:

module.exports = {
  presets: [
    '@vue/app'
  ],
  sourceType: 'unambiguous'
}

HT this comment by #t2t2

[dkebler]

that took away the warning but the issue remains.

I edited the transpiled code to

var _ = require('@feathersjs/commons')

and now my app at least loads. Can't say if _ is the proper object that f-v needs. @marshallswain should I open another issue or can you reopen this issue?

looks like this.

_: Object { each: each(), some: some(), every: every(), … }
​
__esModule: true
​
createSymbol: function createSymbol()
​
hooks: Object { ACTIVATE_HOOKS: Symbol(__feathersActivateHooks), createHookObject: createHookObject(), defaultMakeArguments: defaultMakeArguments(), … }
​
isPromise: function isPromise()
​
makeUrl: function makeUrl()
​
stripSlashes: function stripSlashes()
​
<prototype>: Object { … }
service-module.getters.js:15

In the meantime I guess I will fork it and make the correction. Don't use typescript but hopefully the build script will make it easy?

(BTW I don't use typescript (use latest node es6 with esm, https://www.npmjs.com/package/esm) to avoid the cryptic messages like typeError: commons_1.default I wish the sourcemaps could refer back to the original ts. On top of that by the time transpiled ts runs through babel as well it's hopeless.

[marshallswain]

@dkebler if you want to message me in slack, we can jump on a call to investigate the issue.

[dkebler]

let me just see if I can fix this one thing and refactor my old code for 2.0 and see if I can get it working first

[dkebler]

totally weird. I forked and cloned and opened the ts branch. I see that commit that fixed it and it remains so in 77,

import sift from 'sift'
import { _ } from '@feathersjs/commons'
import dbCommons from '@feathersjs/adapter-commons'
import { globalModels as models } from './global-models'
import _get from 'lodash/get'
import _omit from 'lodash/omit'

BUT if I look in node_modules in my app clearly 77 is installed

{
  "_from": "feathers-vuex@^2.0.0-pre.77",
  "_id": "[email protected]",
  "_inBundle": false,
  "_integrity": "sha512-hBbwwxfjDqkSoQVM0sajZB+guTiuOamDXAcnbdNFPpVbUfPX6xS3J3SQHDjNLsEkawBFmNuKQ4e20NtvDH9tKg==",
  "_location": "/feathers-vuex",
  "_phantomChildren": {
    "debug": "4.1.1"
  },

YET the ts code for that getter module in node_modules is the old code

/*
eslint
@typescript-eslint/explicit-function-return-type: 0,
@typescript-eslint/no-explicit-any: 0
*/
import sift from 'sift'
import commons from '@feathersjs/commons'
import dbCommons from '@feathersjs/adapter-commons'
import { omit as _omit } from 'lodash'

const { _ } = commons

So I made a little test app that just loads f-v package correctly and all is as it should be.

So I did a npm i [email protected] again
and now the correct code is in node_modules

Wow some weird npm/cache issue?? I'm using 6.10.3. I had scrubbed node_modules and did a complete install that had the old code but similarly to some others who said they re-installed just f-v again and it went away it did for me as well :-)

So still need to refactor for 2.0 but you can close this issue again. @marshallswain

[marshallswain]

@dkebler Ah. Well that's really weird, but also good news for me. Thank you for the update.

[marshallswain]

This is now fixed in [email protected]. Thank you @falkodev for making the PR.