transpile to what? Its ES5 already if I see this correctly
It's ES2017 (which makes it ES8 I guess) but more importantly the transpile step could add the polyfills for Buffer, etc.
yeah, the polyfills seam to be missing at stackblitz, but this is not the case in my real app. There I just have the issue with the missing finished from readable-stream.
@angelo-v thanks for creating the issue. i started to use the function also in some other packages (not rdfjs), hopefully prevents any trouble for these packages.
also i still don't get why it get's overwritten with the code you posted the link to. the idea of the readable-stream package is to have a stream implementation which is consistent on all node versions and in the browser. if it gets overwritten, it's almost like using the stream package and rely on the node version people are using.
The code base that is re-exported in readable-browser.js is the same as in readable.js so it should be no difference. It's just that some parts in readable-browser.js are missing for unknown reason. But good question, why even having the readable-browser.js if it exports the same?
yes. i think the code is there to map the stream package to readable-browser.js. maybe made sense once, but maybe it's better now to just map stream to readable-stream.
oh bugger, I just got the same problem with finished
@csarven as far as i remember, the way you used simplerdf it would be better for your to use the dataset directly or clownface
i will move the packages i started in the rdfjs github organization to rdfjs-base. i will handle them like rdf-ext packages. so not to much should change, but i can avoid asking in the big round if there are bigger decisions to make, which cost me a lot of time in the past.
hey. is there a JS in-memory triple store with SPARQL Update support?
@tpluscode i've asked more or less the same some time ago
Hi all :wave: We're starting to build Hydra-based APIs so are adopting linked data. We've started with plain JSON-LD, but are looking at making use of RDF/JS in libero/article-store#64. Would be interested in any feedback, comments or suggestions. Would also be interested to find out about best practices on mixing static (eg Hydra collection) and dynamic (eg items in the collection) statements, as well as access control (eg not exposing parts of the Hydra API doc when you don’t have permission for an operation, or only exposing some statements that make up an item (eg article stored in a database) if you don't have permission to see all of it). Also, advice on persistence would be great, especially in using Postgres rather than a triple store (more details on libero/publisher#292).