Hello,
I am in the process of migrating an application from 2.16 to 3.0rc (was .2, is now .4).
And, suddenly, yesterday, the client side has stopped working !
I mean that :
console in my Chromium browser stays empty
even just a console.log( 'here' ); in client/main.js doesn’t appear
while, server side, all common and server code run and logs just fine.
I have rebooted
I have tried to reverse one, then two days of commits without any change.
I have ugraded from -rc.2 to -rc.4 without any change.
A Firefox browser exhibits the same (lack of) behavior.
Another symptom is that modifying server or common code rightly restarts the server, while modifying client code has no effect at all (and in particular not “client refreshing” display).
All happens as if the client browsers do not reached the Meteor server, without nonetheless complaining that http://localhost:3003 would be not found.
And a netstat shows that the server is listening on the port, and browsers are connected.
When there is a syntax error somewhere, I see an error message or an exception.
Where I have accidentally created a reactivity loop, at least the brower was running (without end, but running).
But there, nothing happens at all. Even the “HMR connected” line doesn’t appear.
One more time:
common and server code run just fine
client doesn’t work, even if the client/main.js only contains a single console.log( ... );.
Not only I am stuck, but I don"t have any idea how to debug that ?
Does anyone would have any idea on how, on what, or on anything ?
Thanks (a lot) for your help !
Had a new idea : as I make a significant use of business and applicative packages, I have all removed and re-added one per one.
Bingo : have identified one package which creates the issue.
To be done : identify the wrong commit + understand
See you later…
The @bgcolor variable was not defined
So, yes, this is wrong, and I should have thought to fix that when modularizing this code.
But:
I believe that, maybe, less could have warned somewhere about that
I didn’t imagine that such an error would lead to such behaviour. This is rather weird…
And rather costly, too : a whole day to try almost everything, until having the good idea which led to the solution…
There’s possibly two things in Meteor 3 that caused this issue:
How Meteor 3 handles errors from compiling stylesheets has a number of work arounds and temporary fixes. At one time there was an item on the plan for Meteor 3 to fix it, but it seems to have been removed. Normally less issues are gracefully handled, but I wouldn’t be surprised if there were some code paths that don’t work correctly.
Meteor silently ignores errors during part of the build process, which can result in Meteor trying to run a broken app. I created a pull request a year ago to fix it, but it seems to be waiting on the stylesheet issue to be properly fixed first.
