@zodern Is there a way to tweak the babel configuration used for recompilation of node modules? What am I doing wrong?
My first suspicion was with the Node version. As you can check in the package.json of this version, they specify that this version works with Node 18 or above.
However, I also tried to use this library with Meteor 3 and got the same error, even after installing the @babel/plugin-transform-private-methods and adding it to my .babelrc.
I’m not sure why this is happening. I could spend some time later trying to figure this out. But I’m not sure what else I could try.
3 Likes
@denyhs If that changes anything, you can try pdfjs-dist@v3.5.141, it is the first version to cause this problem.
Hello,
do you habe any update on this? I’m experiencing the same issue.
@nerlach I am curious about your need for PDF. Do you just need a viewer of PDF files in the browser?
This has been recently featured in JavaScript Weekly: https://pdfslick.dev/
No, we actually need functuality to render and search in pdf files in a more sophisticated way then what a simple pdf viewer can do for us. Afaik, pdfjs is the standard tool for that use case in browser contexts.
Hi @nerlach, sorry for the delayed answer here. I couldn’t find anything that could help with this issue. Did you try anything else?
@denyhs No worries. Unfortunetly, imho the pdfjs documentation itself is not very clear on how to use it with npm. And for now, i am unsure on what i could try next. We could probably build pdfjs by itself and update it manually. With npm, i currently see no other way than downgrading pdfjs-dist from 4.x to version 2.x, where the newer babel features are not used.
1 Like
Using meteor 3.0.2 and same problem.
You can try to get it async from one of the CDNs GitHub - mozilla/pdf.js: PDF Reader in JavaScript which is probably the best way given the size of this library.
Otherwise, pdfjs-dist is just a build generated from here: GitHub - mozilla/pdf.js: PDF Reader in JavaScript The repo has all the instruction for you to build whatever version you want, more or less modern.
Babel in Meteor and modern/legacy build has always been … quantum compilation for me. I just take what I am getting from that build and say “thank you” for another free deployment but otherwise I have never trusted the system to draw a clear line between legacy (what I want to be legacy) and modern(what I want to be modern).
Hi,
im hitting the same problem. As soon as I upgrade the pdfjs 4.x it crashes “Class private methods are not enabled. Please add @babel/plugin-transform-private-methods to your configuration.”
It makes no difference if I install from npm oder build it mysqld from pdfjs github source code.
How can I enable those babel plugins? Using an old 3.x version of pdfjs is not good, since its very old and has vulnerabilities.
Thanks
Did you build yourself from source for legacy?
Yes, I tried legacy as well as generic.
npx gulp generic
npx gulp generic-legacy
Doesn’t make a difference
I think I have made progress on this. But first let’s link to some posts that all point to the same problem:
- Meteor 3.0-rc.1 is out! - #14 by nigelcunningham
- [Solved] Conditional Chaining in NPM package - #4 by marklynch
- Transpile certain node_modules with Babel at Meteor-Build - #5 by crapthings
In short, package.json#meteor.nodeModules.recompile does not honor the babel configuration for the source files (.babelrc or package.json#babel), it just uses whatever is the default babel configuration that ships with Meteor. I figured this out by fiddling with the code under node_modules/@babel/* which runs for source files but not files under node_modules. The code that seems to run for recompiled node modules is under .meteor/local/dev_bundle/lib/node_modules/@babel/*.
Note that package.json#meteor.nodeModules.recompile is not documented for Meteor 3.0, but the problem was already present in Meteor 2.16.
The only working solution is the one suggested at Transpile certain node_modules with Babel at Meteor-Build - #2 by macrozone symlink the node_modules source files into your application source files to subject them to the same babel config. Currently evaluating if there are any drawbacks.
@nachocodoner Is the modern builder of Meteor 3.3 designed in the same way? With different rules for sources and recompiled NPM packages?
I’m not entirely sure about this use case. Since SWC only replaces Babel at compile time, I think recompilation and other configs should work the same way. I’ll revisit this to understand the behavior and its implications.
So your issue is that these recompilations aren’t picking up your custom .babelrc in legacy mode or your .swcrc in modern mode?
Root cause for my problem seems to be described here: Allow private methods on the server. · meteor/meteor · Discussion #13272 · GitHub.
Another GitHub issue referencing this problem:
The solution proposed by @captainn does not solve the root problem, it only suggests transforming import statements in the app sources themselves.
Same problem here, but with local Meteor packages: