empty array element require elision=true

é,
this works for you (gets rid of the warning):

const u = undefined;
const lL = [u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,2,2,u,4,u,u,u,0,4,4,u,5,u,3,2,4,0,1,u,u,u,u,u,u,u,u,2,2,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,4,u,4,u,u,u,4,4,3,3,3,3,5,5,2,3,4,3,6,4,3,6,4,5,3,3,3,4,5,4,5,4,u,u,u,u,u,u,2,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,u,4,u,4,u,u,u,u,3,3,3,3,3,u,u,2,2,u,u,u,u,3,u,3,u,u,3,u,3,3,u,u,2];
for (const l of lL) {
  if (l == undefined) {
    console.log("vide");
  } else {
    console.log(l);
  }
}

Espruino JavaScript interpreter works anyway... with your original as well as with this editor satisfying code above.

If you have more, longer ones or more sparse ones of those arrays, a different way to initialize may save you space if space is an issue. For a space optimal initialization range of the values can be considered in the filling algorithm. I'll add another post about that.

I'm sure you are aware of the differences of

for (const l of lL) {

and

for (const l in lL) {

.

TL;DR: - in regard of elision

The IDE editor has a linter that by default obviously dislikes elision / trailing commas for empty values / comma following another comma without a value / token in between.

Elision (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Trailing_commas) is from cleanness of a language not a good thing... and risk misunderstanding (but a desired thing when space and execution speed matter as w/ Espruino. JavaScript has some other creepy thing: line ends can give you the creeps,... and semicolons too. It's the same with spoken languages: if you are not very fluent and someone speaks with a lots of elisions - and local dialects often have that - you have a hard time to understand. The Editor tries to make coding in JS robust and safe, that's why it even flags missing semi colons, even though the language execution allows it. I do not know what happened to the editor in IDE... but recently this multi file edit came in and with that may be a new version of the syntax checker / linter or just a new configuration.

I hope @Gordon can answer what to do in the environment. The editor just speaks of warning... but the code may still run.

PS: from a compiler parser point of view, I always felt the continuation information - in this case the comma - to be misplaced when put at the end - and a coding / logic trap, because most languages do not allow in a list for the last element to have a continuation indicator but no continuation element. For that reason, you see a lot of my code doing the continuation character on the next line (I know that the parser then has to be a bit smarter than a simple line oriented parser is... but since practically all languages require from syntax / tokenizing / non-terminal syntax element / terminal syntax element - or simply said: ignore white spaces (blanks, tabs, new lines), having the continuation indicator together with the continuation element and the list delimiter on a separate line. This relieves you from having to consider wether an element is the last element in the list and also allows you to move lines around / rearranging order of lines as a whole without having to think about this special cases. The only special case is the first element... An example makes that obvious:

var arr =
[ "all" // first
, "objects"
, "are"
, "things"
];

Any moving around of (continuation) lines or adding lines (with leading comma) is a pure editing thing, can be done as a whole line including line end and has no impact on syntax. Only when I have to deal with the very first element, then it needs some thinking.

PS: Because I'm still a of hte Niklaus Wirth programming school, it was never a thing for me, even though JavaScript introduced it in ECMA Script 5 a while ago. I do not like omissions because they are potential traps... (even tough in Espruino I use for space reasons the opposite... so guilty as charge: I can avoid the var aVar declaration in a function and save that space by adding it as a parameter in the parameter list. Even when the caller puts too many parameters there I can get away practically all the times.

NP: The behavior of the forum post editor has changed too (or may be it is the os of the mac or chrome as the browser: more recently, when typing a second (and/or third) blank in a row it is replaced with a fullstop. This makes me crazy when writing code. Try it yourself: Instead of typing a full stop at the end of a sentence, just hit the space twice after the last word. I can see that this is useful for text, but not for code.