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?
@angelo-v what do I need to do?
@tpluscode i'm not an webpack expert, but maybe it could be solved somehow via the resolve logic/config: https://webpack.js.org/configuration/resolve/
maybe if you configure resolve to use a file in your own codebase, use @angelo-v version of https://github.com/angelo-v/readable-stream/blob/master/readable-browser.js and replace
./lib/ with readable-stream/lib/?
let's hope for a quick release....
here we go, please update your dependencies :) https://github.com/nodejs/readable-stream/releases/tag/v3.4.0
It already passes all spec tests, just need to cleanup some things, optimize, and document.
@rubensworks we will use it in the same issue in
rdf-vocabularies, some only return RDFa :)
^ @bergos Could you give a rough pointers on what needs to happen to get SimpleRDF up to date with the recent RDFJS based parsers/serialisers...? https://gitter.im/linkeddata/dokieli?at=5d23774326a152537e4bf01e
you mean in-browser i assume?
check https://gitter.im/rdfjs/Representation-Task-Force, people are talking about quadstore there
can't you package the whole thing into Docker and then run whatever, like Jena/Fuseki?
what you say, I do with end-to-end tests running over actual API
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).
(There's background on our project at https://httpapis.slack.com/archives/C1JP575EX/p1572362193080200 in case it's useful.)