Javascript rules in VS code: "load" syntax for loading other .js files

When editing .js rule files in VS Code, it doesn’t understand the “load” syntax for loading other .js modules, and thus flags any functions or variables from other files. Is there a way to fix this, or do we just have to put up with it?

If someone provides a language implementation or LSP features yes.
But i doubt that there will be a solution on short term.
So for now the answer is: No way to fix it currently.

JSR223 in general is currently not covered by the extension.

Okay

I think I’m going to use the following workaround: use import directives in my local rule copies to keep VSCode happy, and then execute this Powershell script, which strips the import directives out, to deploy the rules to the RPi:

$sSourceFolder = "E:\Documents\OpenHab\Rules"
$sTempFolder = "C:\Temp\Strippedjs"
$sDestinationFolder = "\\openhabianpi\openHAB-conf\automation\jsr223\javascript\personal"

# Create temp path if it doesn't exist
if ((Test-Path $sTempFolder) -eq $false)
{
	md $sTempFolder
}
	
# Find all .js rule files 
$jsFiles = get-childitem ($sSourceFolder + "\*.js" )
 
# Copy .js files to temp dir              
$jsFiles | foreach ($_) {
	$currentFile = $_; 
	Copy-Item -Path $currentFile.FullName -Destination ($sTempFolder + "\" + $currentFile.Name)}               
	
# Strip out all lines beginning with "import"
$jsFiles = get-childitem ($sTempFolder + "\*.js" )

$jsFiles | foreach ($_) {
	$currentFile = $_; 
	(get-content $_) | 
           Where-Object {$_ -notmatch '^import'} | 
           Set-Content $currentFile -force; 
 }
           	
# Copy processed rules to Rpi
Copy-Item -Path ($sTempFolder + "\*.js") -Destination $sDestinationFolder     	
           
# Remove temp directory
Remove-Item $sTempFolder -Recurse

The slash and quote has confused the syntax colouring a bit

What about a try/except? I’m doing this in my Python rules with typing imports so I can get type hints.

try:
  import typing as t
except:
  t = None

I don’t know Python. In Javascript I tried to come up with some clever trick that would exclude the import directives on OpenHab, but I probably don’t know enough.

I mean I’m sure your script works, it just seems fragile and complicated. Javascript has a try/except as well:

try{
  // try this
} catch e {
  // do this if there was an error
}

Unfortunately it doesn’t work. It’s not an execution-time problem: the OpenHab rules engine first checks the code for errors, and when it comes across import it stops.

2021-01-12 18:21:40.803 [ERROR] [org.openhab.core.automation.module.script.internal.ScriptEngineManagerImpl] - Error during evaluation of script 'file:/etc/openhab2/automation/jsr223/javascript/personal/Tado.js': <eval>:10:2 Expected an operand but found import
  import ('./DateAndNumberFunctions.js');
  ^ in <eval> at line number 10 at column number 2

Oh… Well that’s a pain :confused:
That’s all the tricks I had up my sleeve, looks like your script is the way to go!

1 Like

Yeah I prefer it to having half my code underlined all the time. Makes it hard to see the real errors!

Maybe you could add an issue on github and some screenshots/examples over there.

I am not sure if we can make lsp server ignore those imports, but we could try to add those as another language which gets recognised.

So we would at least have a short term solution for the underlines.

1 Like

Recognising “import” certainly sounds easier.
The problem is that VSCode uses typescript for its intellisense.
OK I’ll look into it.

You could use these options in your VSCode settings, either in your workspace file or in .vscode/settings.json.

        "typescript.validate.enable": false,
        "typescript.format.enable": false,

But wouldn’t that turn off all syntax checking?

No, the javascript and typescript settings are separate. It does both types of checking on .js files because they could be JavaScript or TypeScript, this explicitly turns off TypeScript checking.

I did that, but it still needs the import directives anyway, so it seems.

Our LSP server is written in plain javascript, alltough i would prefer typescript.
But LSP is a different topic…

What i would have in mind is a embedded language.
(But that’s out of my skills and time currently)

1 Like

Even with the above settings VSCode still throws up “ts” errors, because its built-in Typescript extension provides its Javascript intellisense, confusingly. Only javascript.validate.enable=false would kill it, but then you’d lose all syntax checking. So I’m sticking with my script for now.

You can also ignore certain errors, but that scatters // @ts-ignore comments throughout your code, and also (I imagine) implies that the whole line is ignored for syntax checking, which I’m not keen on at all. I managed to get it down to about 8 errors.