Hello,
I'm developer of the @lunatone/node-red-dali package and there is the strange issue that on the flows.nodered.org page of the package some nodes are not displayed in the nodes bubble anymore.
Anyone knows how to fix this?
Thanks in advance!
Hi @MoonDev
As you have chosen not to provide any GitHub / support links to your repo - its incredibility difficult to debug (and for anyone to raise a support request in the future)
So, may be advise what Nodes you have registered in your package.json
and the source code you have written to register these correctly.
Do note: The bubbles are based on (I believe) the registration you have provided in the html files, but the JS file must be registered in the package file
@knolleary - if I have that right?
There is no link to the github repository for the module, so we cannot easily go and look at it to see if we can identify the problem.
1 Like
Personally I am not prepared to put the time in if there is no public repository.
1 Like
Agreed!
But I can be flippant at times 
Not quite right,
When updating the package, the content is parsed by a Regex in order to find all the registerType in script sections in HTML files.
Your problem is:
HI @MoonDev
The flow library attempts to parse the node html files to identify what nodes are contained - also allowing it to try to get the icon/colour right etc.
For security, it doesn't run any of the code, so is reliant on parsing the content to spot the calls to registerType. It isn't a perfect approach, and does fail to spot some nodes. For example, modules that dynamically generate the content, or that load the content for additional files.
Nick
It reads the package.json file to understand what HTML files it needs to parse.
Unless it scans the whole package for .html files @knolleary?
if the former - the package.json is the first breadcrumb so to speak?
For me, only the package.json is read (to find html files).
Hence 
Reads package file -> enumerate the nodes in that package xxxxxx.js
parse xxxxxx.html for the corresponding js file.
(This is just a guess mind you 
)
I do agree with Nick, the flow library thing is a bit left-field (with various things)
1 Like
- it reads package.json to identify the html files to scan - just as Node-RED itself does.
- it parses the html files looking for the nodes.
It does this first by looking for <script type="text/javascript> ... </script> blocks via a regex. It then passes the contents of that into a JavaScript parser and then looks for the call to registerType. So it is a bit smarter than just a regex match once it has found the script tags.
Relevant code: flow-library/lib/modules.js at master ¡ node-red/flow-library ¡ GitHub
2 Likes
Does that mean that, if the registration is done in a resource file <link>d in the HTML rather than in-line, it won't find things?
1 Like
I believe that assumption is correct.
-
Targeting the HTML file : flow-library/lib/modules.js at e103f7091c8c87699761ab5b9802fd7afd68c46d ¡ node-red/flow-library ¡ GitHub
-
Reading the tag contents ONLY : flow-library/lib/modules.js at e103f7091c8c87699761ab5b9802fd7afd68c46d ¡ node-red/flow-library ¡ GitHub
Oops! Unfortunately, that is going to be a bit of a problem for any future releases of any of my nodes because I am/have decoupled the JS from the HTML.
I got really fed up of trying to manage 3 separate things in one HTML file. For a long time I split them in source and used an automation to recombine them on change. But that too was a rather a faff. So now the JS is loaded from a separate resource file.
This has some major advantages, especially for more complex nodes. Specifically, all of the Editor JavaScript code is now in a folder that contains no Node.js code. Meaning that I can now properly use ESLINT to validate the code. And, of course, having the JS separate makes the editing process easier anyway since you can have the HTML and the JS in separate edit windows in VSCode.
Even the panel HTML and the help HTML are in separate files because the help goes into a locales sub-folder. This too makes writing the documentation easier since you can cross-check against the main HTML it separate windows of your code editor.
Ah! there is an election debate tonight 
1 Like
Thanks for all your responses!
Ok, this is probably the reason why some of my nodes are missing on the flows page. I'm using a script block with type="module" for some nodes because I wanted to import common code to use it in the html files. I thought I can do it this way because the nodes show up in the editor and are functional.
Is there any other way to do such thing?
Specifically I would like to access a constant array of objects in my js file and the html file.
1 Like
The main thing is whether your nodes work in node-red. If you have something that works for you - then great - I wouldn't change it.
Sounds reasonable.
For the future would it make sense to extend this check for registerType to include this <script type="module"> ... </script> blocks as well?
While I'm not currently using modules (though that is a good thought and I should consider that), I am otherwise doing the same as yourself, this absolutely works as explained above.
Not just for type of module, this should work as well: <script src="./resources/node-red-contrib-uibuilder/uib-file-list.js"></script>
It seems like the flows site code needs a tweak to ensure that it picks up all of the nodes - actually I'm slightly confused (not difficult) why it doesn't simply use the data in the package.json - why does it need anything else?
The information in package.json is not a list of nodes in the package. It is a list of the node files. A single file could contain multiple nodes. Plus it needs information about the node icon and colour so it can attempt to produce a roughly accurate looking node - information that is only provided in the call to registerType.
I have just pushed a fix that adds support for type="module" script blocks - and can confirm that works for your node @MoonDev . As the parsing is only done when a new version is added to the library, the next time you publish a new version, it should sort itself out.
@TotallyInformation you are technically right that we should treat bare <script> blocks as javascript - will push an update for that shortly.
