next.js example hot reloading bug

I love this loader! Great work!!

Unfortunately, I believe I’ve found a bug in the next.js example. The bug is that the new types that are generated by graphql-let as part of the next-js hot reload action seem to be ignored by the typechecker.

Reproduction steps

1. npm run dev
2. Make a change to the schema (e.g. Add a field isActive: Boolean to the User type in the schema). Save the file.
3. Add this new field to the Viewer query. Save the file.
4. Add a reference to this new field after the query hook on the index view. Save the file. e.g.:

import withApollo from '../lib/with-apollo'
import Link from 'next/link'
import { useViewerQuery } from '../lib/viewer.graphql'

const Index = () => {
  const { data } = useViewerQuery()

  if (data && data.viewer && data.viewer.isActive) {
    const { viewer } = data
    return (
      <div>
        You're signed in as {viewer.name} and you're {viewer.status} goto{' '}
        <Link href="/about">
          <a>static</a>
        </Link>{' '}
        page.
      </div>
    )
  }

  return <div>...</div>
}

export default withApollo(Index)

1. In a browser, navigate to localhost:3000

Actual Behavior

New types are ignored: type error reported according to the types initially generated at app start: Killing the next.js process and starting it again seems to provide the correct types until another change to the schema occurs i.e. it seems that this bug only occurs during the next.js hot reload action.

Expected Behavior

During the next.js hot reload action, graphql-let properly replaces the generated types with the latest and this is reflected properly by the typechecker.

[piglovesyou]

@deanslamajr Amazing work. I put "*" without consideration, perhaps I might have thought it would respect other deps’s globby and would save a number of total deps or something. I really appreciate your deep investigation and the PR, and slash too, which may make another issue in the future.

Let me close this issue now thanks to your PR. Please let me know if you notice something about graphql-let in your project.

[deanslamajr]

I think I’ve found the cause of this bug:

The major version of globby is not “locked” in package.json. Consequently, if another package has a dependency on a major version of globby that is too old for graphql-let, graphql-let will use the incorrect version and function incorrectly.

To verify this, there are two different paths to initialize the the next.js example. The first will install a major version of globby (globby@11.0.0) that supports graphql-let correct functionality:

npm init next-app --example with-typescript-graphql with-typescript-graphql-app

The second path will install a much older major version of globby (globby@^6.1.0) that seems to break graphql-let’s stale asset removal:

[e-mail]:zeit/next.js.git
cd next.js/examples/with-typescript-graphql
npm i

I was able to verify that by locking the major version of globby to the latest major version (11.0.0), this bug can be avoided. I have created a PR to implement this change.