Community
Participate
Working Groups
1) clone in Web IDE https://github.com/snorthov/minesweeper-objects.git/ 2) click on app.js. 3) drill into public/js/main.js 4) BUG: there are tons of warning 5) Refresh the page 6) the warnings go away
There seems to be a timing issue happening here - if I introduce a delay when the loadEagerly entries from the .tern-project file are being loaded, it all works as expected. Debugging through and it seems that when the bug happens, all of the type infos are in the 'maybe' state in Tern, whereas when you refresh the page it definitively knows the types of Board and Counter.
This worked in the past. Olivier helped debug it. You could ask him. As discussed, please get to the bottom of this ASAP so we can decide next steps.
(In reply to Steve Northover from comment #2) > This worked in the past. Olivier helped debug it. You could ask him. As > discussed, please get to the bottom of this ASAP so we can decide next steps. I confirmed this is not a regression from 14. Opening either Board.js or Counter.js also causes the linting to go away. Curtis was the person that worked on this rule last time - and the fix for the linting rule is simple - but the underlying problem is that the types for board and counter are not being made "real" in Tern until they are directly referenced - Tern loads the files correctly, parses / processes them, but since they export into the global scope they are considered "maybe" types. I am in the process of debugging the type creation / addition strategies to see where the failure is (in Tern). For what its worth, I also updated to the latest Tern as a test and the problem still exists.
Ok, I guess it happened less often in Orion 14 because this is a pattern I do a lot to quickly check whether the tooling is working. I'm on the edge of my seat ...
(In reply to Steve Northover from comment #4) > Ok, I guess it happened less often in Orion 14 because this is a pattern I > do a lot to quickly check whether the tooling is working. I'm on the edge > of my seat ... After more testing, it boils down to loading order via the .tern-project file - which affects if the types are made "real". If you change the .tern-project to: { "libs": ["ecma5"], "ecmaVersion": 5, "loadEagerly": [ "public/js/main.js", "public/js/board.js", "public/js/counter.js" ] } or change the index.html file to (leaving the .tern-project file to load just the html file): <head> <title>Minesweeper</title> <link rel="stylesheet" type="text/css" href="css/board.css" /> <script src="js/main.js"></script> <script src="js/counter.js"></script> <script src="js/board.js"></script> </head> everything works as expected. I'm still hunting down the code that is causing the unexpected type creation - since it shouldn't matter when the type is loaded (especially since it is not loaded via a modules plugin and is simply exporting a function into the global scope).
Ok, I will use the workaround as necessary. This really did work at some point recently ... or I was getting lucky on timing.
The work around does not work. Casey from Google has a cut of Orion in Google Cloud that does not have the problem. Please coordinate with him to find out when the problem was introduced.
I can't make the problem happen any more. I'm not sure we should close as WORKSFORME just yet. I'll try a bit more when I have some time but let's downgrade the priority.
... and I just got it to happen by clicking around.
(In reply to Steve Northover from comment #9) > ... and I just got it to happen by clicking around. Here are some steps I did to make it happen: 1. clone the repo 2. open /public/index.html 3. reload the page 4. open main.js From this point if you open each of the files (counter.js / board.js) the linting goes away when going back to main.js
Does not happen for me ... how do I know the linting goes away? Are we both talking about all the warnings that come back down the side?
