[email protected] + [email protected] makes hot-reload crash

Created on 28 Aug 2019  Â·  21Comments  Â·  Source: gridsome/gridsome

Description

Hot-Reload makes the app crash from time to time. The cause of the crash is due to graphQL query returning undefined but it is still not clear how to exactly reproduce it. In fact every few changes made to the code, Hot-Reload comes into play and arbitrarily crashes. Only another hot-reload cycle is able to refresh the page (developer has to change something in the code to trigger a new hot-reload and hopefully refresh the app).

Steps to reproduce

Following is a bash code for the setup.

# Bootstrap
gridsome create reproduce-bug
cd reproduce-bug
npm i --save @gridsome/source-filesystem @gridsome/transformer-remark
mkdir content && touch content/index.md

# Create a markdown file
echo -e "---\ntitle: Homepage\ndate: 2019-09-27 20:25:34\n---" > content/index.md

# Create a graphQL source
echo -e "module.exports = {\n \
  siteName: 'reproduce-bug',\n \
  plugins: [\n \
  {\n \
    use: '@gridsome/source-filesystem',\n \
    options: {\n \
      path: 'index.md',\n \
      baseDir: './content',\n \
      typeName: 'HomePage',\n \
      route: '/'\n \
    }\n \
  }]\n \
}" > gridsome.config.js

# Add query to pages/index.vue 
echo -e "<template>\n \
  <Layout>\n \
    {{\$page.content.title}}\n \
  </Layout>\n \
</template>\n \
\n \
<page-query>\n \
query Homepage {\n \
  content: homePage(path: \"/\") {\n \
    title\n \
  }\n \
}\n \
</page-query>" > src/pages/Index.vue

then the crash occurs when tweaking src/pages/Index.vue in and out while saving each changes to trigger Hot-Reload on purpose.

Expected result

After making changes to the code, the app should refresh itself in the browser without error.

Actual result

After adding some html nodes, css classes etc... app crashes, with the output:

vue.runtime.esm.js?2b0e:619 [Vue warn]: Error in render: "TypeError: Cannot read property 'content' of null"

found in

---> <Index> at src/pages/Index.vue
       <Root>

as well as

TypeError: Cannot read property 'content' of null
    at Proxy.render (eval at ./node_modules/cache-loader/dist/cjs.js?{"cacheDirectory":"node_modules/.cache/gridsome","cacheIdentifier":"516f046c-vue-loader-template"}!./node_modules/vue-loader/lib/loaders/templateLoader.js?!./node_modules/cache-loader/dist/cjs.js?!./node_modules/vue-loader/lib/index.js?!./src/pages/Index.vue?vue&type=template&id=4bc9d7de& (page--src--pages--index-vue.js:34), <anonymous>:29:42)
    at VueComponent.Vue._render (vue.runtime.esm.js?2b0e:3542)
    at VueComponent.updateComponent (vue.runtime.esm.js?2b0e:4060)
    at Watcher.get (vue.runtime.esm.js?2b0e:4473)
    at new Watcher (vue.runtime.esm.js?2b0e:4462)
    at mountComponent (vue.runtime.esm.js?2b0e:4067)
    at VueComponent.Vue.$mount (vue.runtime.esm.js?2b0e:8409)
    at init (vue.runtime.esm.js?2b0e:3118)
    at merged (vue.runtime.esm.js?2b0e:3301)
    at createComponent (vue.runtime.esm.js?2b0e:5972)

where content is the query alias defined in src/pages/Index.vue.

Environment


Libs:
- gridsome version: 0.6.8
- @gridsome/source-filesystem: 0.5.0
- @gridsome/transformer-remark: 0.3.2
- @gridsome/cli version: 0.2.1
- Node.js: 10.15.1


Browser:
- [X] Chrome (desktop) version 71
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX

After reverting gridsome back to "0.6.7" strictly, the bug seems to disappear.
Got a crash after a few minutes of work even using 0.6.7

Most helpful comment

It is such an issue that actually causes a hard time during development. I really wish it could get more attention @igk1972 @hjvedvik :)

All 21 comments

Thanks for the reproduction steps :) I followed them, but I'm still not able to reproduce the error. Not sure if it would mean anything, but which Node.js version are you running?

I use node v10.15.1
I'll edit the issue: I just got another crash using gridsome v0.6.7... so I don't really get what's causing this.

I wonder if the gridsome.config.js + graphQL query are valid:

module.exports = {
  siteName: 'reproduce-bug',
  plugins: [
  {
    use: '@gridsome/source-filesystem',
    options: {
      path: 'index.md',
      baseDir: './content',
      typeName: 'HomePage',
      route: '/'
    }
  }]
}
<page-query>
query Homepage {
  content: homePage(path: "/") {
    title
  }
}
</page-query>

The crash is so random, it feels like a race condition of some sort, I wonder if maybe hot reload has some issues to resolve the query before updating UI.
On a side note, I observed that hot-reload is somewhat forced to refresh the entire page before crashing. Step by step it goes like:

  • I change something in my code (like a class name, or add a node or even just adding a space)
  • I hit save
  • The page gets refreshed ENTIRELY (not like hot reload normally would by just updating a portion of the page)
  • The page turns blank with the console outputting the error I submit in the issue.
  • To recover, manual refresh can't help. I need to repeat the steps UNTIL THE PAGE COMES BACK AGAIN. So I tweak my code back and forth, adding and removing spaces just to trigger hot-reload, and HOPEFULLY the page comes back.

One interesting thing here is that it needs to do a full refresh instead of hot-reloading. Do you get any messages in the console about why it can't hot-reload?

The refresh cleans the console so I activated "preserve logs" and here is what I see just before refresh:

Ignored an update to unaccepted module
./src/.temp/routes.js  ->  ./node_modules/gridsome/app/router.js -> ./node_modules/gridsome/app/entry.sockjs.js -> 0

[HMR] The following modules couldn't be hot updated:  (Full reload needed)
This is usually because the modules which have changed (and their parents) do not  know how to hot reload themselves. See https://webpack.js.org/concepts/hot-module-replacement/ for more details.

[HMR]   -   ./src/.temp/routes.js

[HMR]   -   Reloading page

Also in the logs, I saw a strange warning logged only once after the first update after gridsome develop. Here:

[HMR] unexpected require(./src/assets/background.svg) from disposed module ./node_modules/cache-loader/dist/cjs.js?
{"cacheDirectory":"node_modules/.cache/gridsome","cacheIdentifier":"407d8309-vue-loader-
template"}!./node_modules/vue-loader/lib/loaders/templateLoader.js?!./node_modules/cache-
loader/dist/cjs.js?!./node_modules/vue-loader/lib/index.js?!./src/pages/Index.vue?
vue&type=template&id=4bc9d7de&

[HMR] unexpected require(./node_modules/gridsome/lib/webpack/loaders/assets-loader.js?
alt=Visitor%20profile!./src/assets/profile.svg) from disposed module ./node_modules/cache-
loader/dist/cjs.js?{"cacheDirectory":"node_modules/.cache/gridsome","cacheIdentifier":"407d8309-
vue-loader-template"}!./node_modules/vue-
loader/lib/loaders/templateLoader.js?!./node_modules/cache-loader/dist/cjs.js?!./node_modules/vue-
loader/lib/index.js?!./src/pages/Index.vue?vue&type=template&id=4bc9d7de&

// ...
// and the same for all my other 10 svg images

This warning doesn't crash the app. The app will crash after the next hot-reload call (the next time I hit save). Then this warning won't appear anymore until I restart gridsome and perform another gridsome develop.

I have upgraded to node v12.9.1 this morning and I haven't seen the crash so far... @dweldon could you try to do so ? I use nvm it's pretty cool for that:

nvm install 12.9.1

then I reinstalled all node_modules:

rm -rf node_modules
rm -rf package-lock.json
npm i

I was already running 12.9.1, and I haven't seen any crashes. I'm going to open a separate issue about my problem. If you think the upgrade fixed your problem, maybe we can close this one?

Well, even after node upgrade I confirm its still buggy... I guess it is related to this issue: https://github.com/gaearon/react-hot-loader/issues/1287

I'm facing the same issue :(

@Jonarod By any chance are you running Ubuntu?

I think I am having the same issue on the latest v0.7.8. I am using SanityCMS as the source for data. Not sure if that matters thou.

I have observed that everytime I prototype/edit anything relating to the query data (f. ex. editing class name on v-for element or any child), it just crashes with this error TypeError: Cannot read property 'articles' of null, where articles is the GraphQL query.

I hope this can be addressed fast. I tried multiple major Node versions and clean install, this just drives development nuts. Will try disabling HMR. :)

Yeah I tried everything too, now I am at my third project using gridsome
and whatever I do, at some point I get the crashes.

There is a problem with HMR for sure, I just don't get how to track that,
it's pretty random.

On Sun, Oct 20, 2019, 05:32 Lukas Vanagas notifications@github.com wrote:

I think I am having the same issue on the latest v0.7.8. I am using
SanityCMS as the source for data. Not sure if that matters thou.

I have observed that everytime I prototype/edit anything relating to the
query data (f. ex. editing class name on v-for element or any child), it
just crashes with this error TypeError: Cannot read property 'articles'
of null, where articles is the GraphQL query.

I hope this can be addressed fast. I tried multiple major Node versions
and clean install, this just drives development nuts. Will try disabling
HMR. :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gridsome/gridsome/issues/626?email_source=notifications&email_token=ABOWZT5HNWMCUTHRT46AZ7LQPQXTXA5CNFSM4IQPWK32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBYHDHA#issuecomment-544240028,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABOWZT3DSRJEA5PTZUNRLKLQPQXTXANCNFSM4IQPWK3Q
.

It seems crazy road to get HMR disabled so I just cheated around by creating a computed variable with localStorage cache. I store my data in localStorage and work of that computed one :)

computed: {
    exams() {
        const EXAM_CACHE_KEY = 'exams';
        const ls = localStorage.getItem(EXAM_CACHE_KEY);

        if (ls) {
            return JSON.parse(ls);
        }

        const { edges } = this.$page.exams;
        localStorage.setItem(EXAM_CACHE_KEY, JSON.stringify(edges));

        return edges;
    },
}

I am also experiencing this issue. There definitely seems to be a race condition between file system assets and hmr. Like @jonarod said, it seems to be random, but I have noticed the larger the asset I load the more it seems to happen. If I add a large image as a local asset to use with a g-image, for example, it seems to happen more.

I'm also experiencing this issue right now. I am using the gridsome-starter-blog, while working with my project it crashes every time specially when I missed something on my code. I think it should not crash like that, like Vue CLI does. It should display an error instead of crashing.

It is such an issue that actually causes a hard time during development. I really wish it could get more attention @igk1972 @hjvedvik :)

+1 Got into a completely new project from scratch this week and this bug drives me nuts.

I'm running into this also on node 12.9.1

same issue on node 13.9, ubuntu
very annoying

This is quite a consistent issue for me as well, over several projects I have been working on recently. However, I cannot narrow down solid steps to reproduction, but it does appear to be something in how the GraphQL schema is rebuilt (since it is always GraphQL related variables that are null or undefined, such as page, etc).

For example, given the error TypeError: Cannot read property 'project' of null it will point to the GraphQL related object.

export default {
  name: "Project",
  computed: {
    project() {
      // ERROR
      return this.$page.project;
    },
  },
};

I aggree with @kendallroth that this one is hard to track down, but I noticed that it happens when I edit HTML markup of a component that contains children using page data. Say I change className on a div that has children rendered from page data and then it is likely to fail.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

SteveEdson picture SteveEdson  Â·  44Comments

itech001 picture itech001  Â·  32Comments

kai-oswald picture kai-oswald  Â·  18Comments

LukeXF picture LukeXF  Â·  33Comments

tyankatsu0105 picture tyankatsu0105  Â·  22Comments