On the basis that request is deprecated, as part of looking at the fitbit node (Fitbit nodes - working? - #4 by borpin), I thought the first step might be to move the module away from request and to node-fetch (looking at the various docs, this seems the best alternative, but not wedded to that).
The current module uses client-oauth2 and request to generate the HTTP requests.
Before I dive in and reinvent the wheel, does anyone have a readymade update to this that will work? Looking through the code, it seems this is the only point that request is actually used, however, I do appreciate that the overall structure might be inappropriate when not using request so may need a more fundamental rewrite (which is probably beyond my skills).
Hi @borpin,
Don't know if you have noticed that the http-request node has moved some time ago from 'request' to got. Perhaps that can also be an alternative for you too? I haven't looked whether it supports oauth...
Bart
Yes true, but when searching for examples and answers to questions is it one of the worst names possible. Why not http-got. Other names than are in the same positon was the UK firm Thus (didn't last long as a brand) and JC (which is really useful but too few letters to search on).
Looking at the SRC you linked to in the OP, the node uses OAuth2. If you search the issues for OAuth2 on the got repository there are quite a few clues. For example this: How to OAuth · Issue #219 · sindresorhus/got · GitHub
Moving from request is not going to be done by me - simply do not have the knowledge.
The issue is that this Fitbit node currently used the require syntax to import and the got module requires the import syntax.
The 2 cannot coexist (it seems) so I'll have to stick with request.
Yes I have now found that source of info - thanks. Again though, I'd suggest finding this under 'issues' is perhaps not the most user-friendly way . [edit] Also, that post was 2016 and refers to Oauth1!
I'd also point out that the NPM page for got is basically blank (got - npm). This doesn't help its cause.
I'll just have to move on and see if I can adapt what is there for the newer API syntax.
Dec 31 09:35:55 nrtest Node-RED[1041]: 31 Dec 09:35:55 - [info] Node-RED version: v2.1.4
Dec 31 09:35:55 nrtest Node-RED[1041]: 31 Dec 09:35:55 - [info] Node.js version: v16.13.1
Dec 31 09:35:55 nrtest Node-RED[1041]: 31 Dec 09:35:55 - [info] Linux 5.4.78-2-pve x64 LE
Dec 31 09:35:58 nrtest Node-RED[1041]: 31 Dec 09:35:58 - [info] Loading palette nodes
Dec 31 09:35:58 nrtest Node-RED[1041]: 31 Dec 09:35:58 - [debug] Module: node-red-contrib-fitbit 1.0.9 /root/.node-red/node_modules/node-red-contrib-fitbit
Dec 31 09:36:04 nrtest Node-RED[1041]: 31 Dec 09:36:04 - [warn] ------------------------------------------------------
Dec 31 09:36:04 nrtest Node-RED[1041]: 31 Dec 09:36:04 - [warn] [node-red-contrib-fitbit/fitbit-credentials] Error [ERR_REQUIRE_ESM]: require() of ES Module /root/.node-red/node_modules/got/dist/source/index.js from /root/.node-red/node_modules/node-red-contrib-fitbit/oauth-helper.js not supported.
Dec 31 09:36:04 nrtest Node-RED[1041]: Instead change the require of index.js in /root/.node-red/node_modules/node-red-contrib-fitbit/oauth-helper.js to a dynamic import() which is available in all CommonJS modules. (line:2)
Dec 31 09:36:04 nrtest Node-RED[1041]: 31 Dec 09:36:04 - [warn] [node-red-contrib-fitbit/fitbit] Error [ERR_REQUIRE_ESM]: require() of ES Module /root/.node-red/node_modules/got/dist/source/index.js from /root/.node-red/node_modules/node-red-contrib-fitbit/oauth-helper.js not supported.
Dec 31 09:36:04 nrtest Node-RED[1041]: Instead change the require of index.js in /root/.node-red/node_modules/node-red-contrib-fitbit/oauth-helper.js to a dynamic import() which is available in all CommonJS modules. (line:52)
:~/.node-red# npm list got
node-red-project@0.0.1 /root/.node-red
`-- got@12.0.0
I'm definitely missing something .
I note the example from core has the require under the module.exports = function (RED) statement. I have tried it there (and in other places to see if it would work).
Actually, you might get away with a peer dependency of ^11 of got in your fork & when a user installs the node, it should (might) pick up the got version installed by node-red (unsure/untested)
Got made the change to using ESM modules after 99.9% of the work to move to it from request in the http-request node had been done so we pinned it at v11.x rather than start again with another new library.