Yeah, but in my case I was using your http package (which is awesome by the way) but subsequently moved to fetch, so it is not even in my bundle anymore. Nor do I have the http or request package as a direct dependency since I don’t call it anymore. The deprecation warning STILL occurs, from somewhere in the Meteor code (see stack trace above). If I understand you correctly, Meteor itself still uses it even though I do not, and that somehow I can replace this dependency with your package and the warning will go away? Or that there is a branch of Meteor that does this? Not sure exactly what I am supposed to do.
@rjdavid I did exactly what you suggest. I removed http and added jkuester:http. Then I rewrote all my uses with node-fetch. Then I removed jkuester:http. So there is theoretically no http package in my build. meteor list doesn’t show it
shartman@LAKEDEV:~/glo/dev$ meteor list --tree | grep request
shartman@LAKEDEV:~/glo/dev$ meteor list --tree | grep http
shartman@LAKEDEV:~/glo/dev$ meteor list --tree | grep parser
I removed all global npm packages and I still get the warning. I will be damned if I can figure out where it is coming from. All I have is the stack trace above. I pulled the repos and ag’ed a bit but that wasn’t helpful and I can’t figure out how to get the source maps for the repos into vscode.
That’s exactly the current situation now.
I’m in the same boat out here:
- I’m using the fabulous jkeuster:http
- I am not using the original http
Yet, I’m still seeing a warning (deprecation) message at start-up time:
[[[[[ C:\git\vxframe ]]]]]
=> Started proxy.
W20210414-10:42:07.571(-7)? (STDERR) (node:8584) [DEP0131] DeprecationWarning: The legacy HTTP parser is deprecated.
I20210414-10:42:09.479(-7)? meteor-emails utils.js sass *init* unconditionally returning node-sass
I20210414-10:42:10.961(-7)? startup.js (vx) VXFrame 1.4.4 Node.js v12.22.1 Meteor METEOR@2.1.1 port=20741 environment=development nobatch=no logLevel=5
I believe the cause is this
'use strict';
var NodeHTTPParser = process.binding('http_parser').HTTPParser,
version = NodeHTTPParser.RESPONSE ? 6 : 4;
which I find in
.meteor/packages/ddp-server/.2.3.2.1jl3owp.wpsuf++os+web.browser+web.browser.legacy+web.cordova/npm/node_modules/websocket-driver/lib/websocket/
The http_parser that line uses is deprecated and node spews the warning.
I think that previous posters are implying there is a branch of meteor which uses the jkuester approach to the http package but merely adding jkuester:http does not fix it for me.
2 Likes
Clearly, Meteor should simply implement the jkeuster approach, in hindsight this seems obvious.
To those looking to remove the deprecation warning while waiting for an updated meteor build that solves this, here are the complete steps that I did
- Checkout
jkuester:httppackage to another folder outside my project. GitHub - jankapunkt/meteor-http: Make HTTP calls to remote servers using fetch API. Fork of the core http package. - Copy or symlink the folder to
/packages/http - Open the file
/packages/http/package.jsand update the name of the package fromjkuester:httptohttp
@jkuester created a new branch so that you can skip item no. 3 above. Here is the new branch: GitHub - jankapunkt/meteor-http at core-replacement
1 Like
Tried many iterations of these steps and none worked for me to remove the error. I believe @bogometer found the real cause
You guys might be experiencing a different warning than we did. It will need a different fix from the core. You might want to open an issue in github
http-parser-js should work via monkey-patching on Node v6-v11, and v13-14.
Node v12.x renamed the internal http parser, and did not expose it for monkey-patching, so to be able to monkey-patch on Node v12, you must run node --http-parser=legacy file.js to opt in to the old, monkey-patchable http_parser binding.
If we discount the use of http package then we will have to go more deeper into the code and see where else the old style is being used. When looking into pre-v1 code I think I came across at least one place where that was the case.
@jkuester @storyteller, this new issue is separate from the deprecation of the HTTP package.
With the release of Meteor 2.1.1, the node version is updated to Node 12.22.1. In Node 12.22.0, node started to display the deprecation warning for the “legact HTTP parser”
The legacy HTTP parser, selected by the --http-parser=legacy command line option, is deprecated with the pending End-of-Life of Node.js 10.x (where it is the only HTTP parser implementation provided) at the end of April 2021. It will now warn on use but otherwise continue to function and may be removed in a future Node.js 12.x release.
Meteor is using this npm package:
- faye-websocket
- which uses: websocket-driver
- which uses: http-parser-js
- which uses: websocket-driver
http-parser-js seems to be overriding the default HTTP parser of node. But it is not possible in Node 12 (possible again for Node 14).
http-parser-js should work via monkey-patching on Node v6-v11, and v13-14.
Node v12.x renamed the internal http parser, and did not expose it for monkey-patching, so to be able to monkey-patch on Node v12, you must run node --http-parser=legacy file.js to opt in to the old, monkey-patchable http_parser binding.
Seems like there are a few ways to fix this:
- Band-aid long term solution: upgrade to Node 14
- Short term solution: update the command called by meteor to start node to add the parameter `–http-parser=legacy
- Long term solution: move away from the old http parser (seems to be through
faye-websocket)
1 Like
Option #1 is already in works and there is already some work on #3 as well.
1 Like
Node 16 is out and it is mentioned that the binding to the legacy http parser has been removed.
https://nodejs.medium.com/node-js-16-available-now-7f5099a97e70
I think this will be tackled together with the Fibers issue, see:
Anyhow from those two I think we will see Node 16 in Meteor earliest in late 2022.
1 Like
As for option #2 the issue there is that it will not get rid of the deprecation warning.
1 Like
I have upgraded faye-websocket in two packages and that seemed to have killed the warning, so at least for the moment we are fine.
2 Likes