feat: add streams guide
Description
This PR adds a stream guide for the learn section
Validation
Lint passing and checked visually
Related Issues
Closes nodejs/node#8646
Check List
- [x] I have read the Contributing Guidelines and made commit messages that follow the guideline.
- [x] I have run
npm run formatto ensure the code follows the style guide. - [x] I have run
npm run testto check if all tests are passing. - [x] I have run
npx turbo buildto check if the website builds without errors. - [x] I've covered new added functionality with unit tests if necessary.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
| Name | Status | Preview | Updated (UTC) |
|---|---|---|---|
| nodejs-org | ✅ Ready (Inspect) | Visit Preview | Nov 17, 2024 11:15am |
I'm missing translation for the titles as I didn't want to use translator ones
I'm missing translation for the titles as I didn't want to use translator ones
You mustn't touch to translation fille it's handle with crowdin
I'm missing translation for the titles as I didn't want to use translator ones
You mustn't touch to translation fille it's handle with crowdin
So should I remove the en.json change?
I'm missing translation for the titles as I didn't want to use translator ones
You mustn't touch to translation fille it's handle with crowdin
So should I remove the
en.jsonchange?
I mean you just have to update en.json and don't touch to translated file
cc @mcollina @Trott
Can you please add a sentence at the beginning or end saying that this guide is a derivative of https://blog.platformatic.dev/a-guide-to-reading-and-writing-nodejs-streams?
@mcollina do we want any corporate references to material that lands on the Node.js website? Asking because, in a similar vein, the article was reviewed by multiple people at Nearform, including myself, and we weren't going to ask @Ceres6 to attribute us.
On the other hand, we were considering to publish the very same article on our company's blog, with a reference to the official documentation, as the authoring has in practice being supported by us.
@mcollina do we want any corporate references to material that lands on the Node.js website? Asking because, in a similar vein, the article was reviewed by multiple people at Nearform, including myself, and we weren't going to ask @Ceres6 to attribute us.
@simoneb You can see there are very few original contributions to what has been added here compared to what I wrote in the article, as multiple paragraphs were taken verbatim, including the whole of the introduction.
By all intents and purposes, I'm the primary author of this PR, and I gave permission to use my original piece if I was included as a co-author of it and kindly asked for a backlink if possible.
Adding a backlink is not unreasonable to ask. It's also ok if it's not added, but I would prefer it.
do we want any corporate references to material that lands on the Node.js website?
I think the question for the @nodejs/tsc is:
Should we add a backlink in case existing material is used in the Learn section of the website?
(We should not be using existing material without the author permission anyway).
Here is a proposal, how about you include in the commit description:
- a link of the original piece
- a mention of all people at NearForm that reviewed it
So we keep a record of the origin of this content.
@mcollina I'm happy to add the backlink. I'm guessing now the TSC is tagged we should wait until that gets discussed, right?
EDIT: I saw that some resources in the learn section have an authors frontmatter prop, maybe that's another option to consider?
I think it's good if the TSC discuss this because I suspect it would come out more and more.
@Ceres6 you should definitely fill in the authors block in the frontmatter. It should appear something like:
Cool! I'll add authors then and wait for the TSC discussion on the backlink. Just one doubt, should I add Nearform reviewers as authors or are those not considered as such? @mcollina
I would list them all.
Hey folks 👋 are we happy here?
Lighthouse Results
| URL | Performance | Accessibility | Best Practices | SEO | Report |
|---|---|---|---|---|---|
| /en | 🟢 100 | 🟢 100 | 🟢 100 | 🟢 91 | 🔗 |
| /en/about | 🟢 100 | 🟢 100 | 🟢 100 | 🟢 91 | 🔗 |
| /en/about/previous-releases | 🟢 99 | 🟢 100 | 🟢 100 | 🟢 92 | 🔗 |
| /en/download | 🟢 100 | 🟢 100 | 🟢 100 | 🟢 91 | 🔗 |
| /en/blog | 🟢 100 | 🟢 100 | 🟢 96 | 🟢 92 | 🔗 |
Unit Test Coverage Report
| Lines | Statements | Branches | Functions |
|---|---|---|---|
| 90.38% (592/655) | 75.43% (172/228) | 94.26% (115/122) |
Unit Test Report
| Tests | Skipped | Failures | Errors | Time |
|---|---|---|---|---|
| 132 | 0 :zzz: | 0 :x: | 0 :fire: | 5.118s :stopwatch: |
Hey @ovflowd, I think we're waiting on the next TSC meeting for the backlink issue.
@ovflowd do you know if we have a policy for content that was published elsewhere and brought in? That's what is missing in this case.
@ovflowd do you know if we have a policy for content that was published elsewhere and brought in? That's what is missing in this case.
The only content-related policy we have is this one https://github.com/nodejs/nodejs.org/blob/main/CONTENT_VS_CODE.md
Nothing else, such as content sourced from different places.
@mcollina Should I add the backlink so we can merge this and we can revisit it if the tsc votes otherwise?
My opinion is that we should include something like "This content was originally shared by Y in X"
I think we should also document in the collaborator guide for the Node.js website that we should include references when pulling in content from other sources. That process should also be to make sure we document that the original author is ok with the content being pulled in, possibly through approving the PR that pulls it in.
Authors and original attribution added. Are we good to go, @mcollina?
Content-wise (first glance) it looks great. @nodejs/tsc I see this is still in the TSC agenda. Any blocker here?
According to the minutes from November 13th, they are still? deliberating on the policy of external content attribution.
Content-wise (first glance) it looks great. @nodejs/tsc I see this is still in the TSC agenda. Any blocker here?
According to the minutes from November 13th, they are still? deliberating on the policy of external content attribution.
As far as I can see there were only opinions in favour of adding them, not sure if there should be a formal ruling or something
It'll be discussed at every-ish meeting while it's on the agenda. Once they remove the label, they should come to a formal dicision.
(Also BTW this isn't the first time we've reposted external content with permission, see https://github.com/nodejs/nodejs.org/blob/83081efa4cde77626228c2709d2585cd554431af/apps/site/pages/en/blog/module/multi-server-continuous-deployment-with-fleet.md?plain=1#L9)
@mcollina did you have time to review it?
@mcollina did you have time to review it?
Bump, @mcollina
Hey folks, this has been here for a couple of months, can we try to move it forward? It's just a guide to be added to the docs.
I believe we agreed that we're going to credit @mcollina and Platformatic explicitly in the content, and myself and @codyzu in the markdown metadata.
I'm happy with that, so unless anybody disagrees, I would suggest to move this forward.