Documentation for v1.3.7

General
1

Looking for old documentation. Specifically for v1.3.7 of node-red. I usually checkout the docs visitng the nodered.org site. Please guide on how to access the older documentation.

2

I'm not aware if we have "frozen" copies of the old docs - especially now that we are up to version 3.x - I appreciate that there may well have been many changes since v1 - What in particular are you looking for ?

3

Why not using a web-archive page to do that?
http://web.archive.org

For example here is the Documentation page from 2020-05-25:
http://web.archive.org/web/20200525115505/https://nodered.org/docs/user-guide/

2 Likes
4

We are trying to setup the tests for custom node-red nodes. There are two repos concerned here. Both are a bit outdated, but largely similar to our internal repos. Explaining the issues per what is publicly available on github.

We programmatically start the server as follows:

RED.init(app.server, settings);

settings variable is a module level variable initialized by initApp() (line 126); which ultimately gets fetched from a file called node-red-settings.js (line 296 & 300). You'll note that it exports an object with the same specs as that of the settings variable (2nd argument to the RED.init() (line 131))

Rush to our other repo, where we maintain a few custom node-red nodes. All the nodes are in their respective folders in the project root. In the test folder we have the same node-red-settings.js file (oe-node-red-nodes/node-red-settings.js at dev · deostroll/oe-node-red-nodes · GitHub)

You may also note that the oe-node-red module is a dev dependency of this project. We have updated node-red (in oe-node-red module) to use 3.x. But now our test fail since the node red initialization process doesn't discover the custom node-red-nodes folders. Currently the tests get stuck at test "t4.2"

I was able to reproduce this behavior through gitpod. You need a local running mongo instance. Each time you run the the tests you need to clear the db created in mongo. Sharing those commands here:

$ ## To clear mongo
$ mongo localhost:27017/oe-node-red-nodes-test --eval 'db.dropDatabase()'

$ ## to run tests
$ node_modules/.bin/mocha --exit --bail --no-timeouts test/test.js

Here is my analysis so far. Inside node_modules/@node-red/registry/lib/loader.js#L42

:point_up_2: In the 1.x version the above function call used to return data correctly. All the necessary custom nodes info would be present at modules['node-red'].nodes. But after the upgrade to 3.x, it is not so.

What is the correct config I need to apply for my tests to work correctly?

5

On further analysis, I found that removing the node-red section from the package.json solves the issue.

But why is that? Is that the recommended way?

6

Hi @dceejay

This could be a potential bug. Ideally I would suggest you self-reproduce following instructions in the previous threads. But here is a summary of the what happens beneath the hood in my own words:

Imagine I have a folder structure similar to oe-node-red-nodes project. And there is a index.js file in which the following code (shortened for brevity) is there:

RED.init(server, { nodesDir: './' });
RED.start();

The initialization call tree is somewhat like follows:

  1. In @node-red/lib/registry/loader.js:L42, localfilesystem.getNodeFiles() is called.
  2. Inside getNodeFiles(), in @node-red/lib/registry/localfilesystem.js:L362, getLocalNodeFiles() function is called with argument './'. The next following points concern with the same file.
  3. In getLocalNodeFiles(), L95, we see that the dir variable is set to the proper resolved path (i.e absolute path).
  4. The above function returns prematurely @ L111. Also make note of the comments L106,107. Further note that in L109, dir variable has the absolute path to the directory.
  5. execution flow is returned back to getNodeFiles() scope, but, next line of interest is L386. scanTreeForNodesModules(). Per notes in comments (L106,107) this should catch the custom nodered nodes folders
  6. In scanTreeForNodesModules(), L248, call to getPackageDetails(). Note, that nodeDir variable has value './', which is not absolute path. This actually makes the function return with an object which has an error property (stating a require() error). This somehow bypasses the required tree scan.

For fix, making the nodeDir value absolute using a path.resolve() might fix it. (L247).

7

Does your analysis explain why the process worked earlier and fails now? You should be able to reconstruct previous versions of NR from GitHub or npm.

Also, you might want to change the title of the discussion to better describe your issue.

8

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.