rdf-parse.js
rdf-parse.js copied to clipboard
parse method is undefined
I did npm install rdf-parse and ended up with
"rdf-parse": "^2.1.1",
in my package.json. Then doing:
import rdfParser from "rdf-parse"
....
rdfParser.parse(someStream, { contentType: 'text/turtle'})
I end up with TypeError: rdfParser.parse is not a function
Could you try import * as rdfParser from "rdf-parse"?
Thanks, @rubensworks! With this one I am getting:
error TS2339: Property 'parse' does not exist on type 'typeof import("PROJECT_HOME/node_modules/rdf-parse/lib/index")'.
23 await rdfParser.parse(S, { contentType: 'text/turtle'})
Also just trying import { parse } from "rdf-parse" yields the error error TS2614: Module '"rdf-parse"' has no exported member 'parse'. Did you mean to use 'import parse from "rdf-parse"' instead?
It looks like here is no parse method exported from the module at all. I tried to see if I could construct an RdfParser object, but that requires an instance IRdfParserArgs for which I'd have to dig in to the depth of something called communica, and I'm not sure that's the intended usage of rdf-parse.
Do you have some sample test code/project I could run?
Perhaps it's a problem with your tsconfig?
Example project where I'm using rdf-parse:
- https://github.com/LinkedSoftwareDependencies/Components.js/blob/be231392dd1c5a87dc05d72c6c58b3b471bc19c6/lib/rdf/RdfParser.ts#L5
- https://github.com/LinkedSoftwareDependencies/Components.js/blob/be231392dd1c5a87dc05d72c6c58b3b471bc19c6/tsconfig.json
@rubensworks Thanks for this example. It really helps to start from a working setup! Comparing tsconfig.json with mine, seems like the main difference is I am using ES6 and not commonjs. I was able to make it work by switching to commonjs. However, I'd prefer to use ES6. Is there any chance of publishing dual packages with conditional exports as explained here.
I'm not super familiar with the node/javascript build ecosystem and I'm not sure if this is best practice or not. Found the suggestion in a SO answer. But seems like when writing new code (as is my case), aligning with the ES6 module standard is the logical choice.
Is there any chance of publishing dual packages with conditional exports as explained here.
The problem is that tooling support for ESM is still quite shaky at the moment. Moving to ESM is something I definitely want to do in the future, but I think it's a bit too early for that at the moment.
Any updates on this? (:
No, we don't support ESM yet. CJS-only.
@bolerio suggested using a dual export mechanism, that would make the module work with both ES6 and CJS, and/or publish 2 different packages.
That way you can use your CJS tooling, and maintain ES6 compatibility. Forcing people to move to CJS makes integrating with existing projects harder than it has to be.
As of v3, we have a named export that fixes this problem.