orbitjs / orbit

Composable data framework for ambitious web applications.
https://orbitjs.com
MIT License
2.33k stars 134 forks source link

Can not create MemorySource #933

Closed towerhe closed 2 years ago

towerhe commented 2 years ago

I try to run a test with vitest. It throws an error when creating an instance of MemorySource:

FAIL  test/unit/menu.spec.ts [ test/unit/menu.spec.ts ]
TypeError: Cannot read properties of null (reading 'nextTick')
 ❯ Object.<anonymous> node_modules/@orbit/record-cache/dist/commonjs/live-query/live-query.js:86:41
 ❯ Object.<anonymous> node_modules/@orbit/record-cache/dist/commonjs/live-query/sync-live-query.js:4:22

My test codes:

const schema = new RecordSchema({
  models: {
    menuItem: {
      attributes: {
        path: { type: "string" },
        title: { type: "string" },
        icon: { type: "string" },
        disabled: { type: "boolean" },
        hidden: { type: "boolean" },
      },
      relationships: {
        parent: { kind: "hasOne", type: "menuItem", inverse: "children" },
        children: { kind: "hasMany", type: "menuItem", inverse: "parent" },
      },
    },
  },
});

const memory = new MemorySource({ schema });

test("create an memory source", () => {
  // nothing here
});
dgeb commented 2 years ago

I'm not seeing any code that would instantiate a liveQuery, which makes the error message and trace confusing. Any chance you could reproduce your problem in a fork of this codesandbox or in a public repo?

towerhe commented 2 years ago

@dgeb I pushed a test project to https://github.com/towerhe/orbit-vitest.

It can reproduce my problem.

Thanks !

dgeb commented 2 years ago

@towerhe thanks for the reproduction! That helped me narrow the issue down to an edge case in the environment check (in which the process global could be null instead of undefined). I've patched this in #937 and will get a patch release out soon.

Incidentally, I was surprised to see the commonjs dist being used instead of modules (ESM). I'm new to vite and vitest - is this unexpected to you as well? Can you configure vite to prefer modules instead of main?

dgeb commented 2 years ago

Fix included in v0.17.2

towerhe commented 2 years ago

I am also a newbie of Vue + Vite community. By looking through the doc of vite and vitest, es modules should be used first.

After checking the deps of my project, I found some deps are distrubuted as commonjs modules e.g. @testing-library/vue. This commonjs deps maybe cause vite and vitest to change the resolving policy.