Implemented new package to sync to external repositories

[SergioCasCeb]

The package docusaurus-plugin-remote-content was implemented to read and duplicate markdown files from external repositories.

[netlify]

✅ Deploy Preview for thingweb ready!

Name	Link
🔨 Latest commit	302c742
🔍 Latest deploy log	https://app.netlify.com/sites/thingweb/deploys/67d411912db3da00088a26b8
😎 Deploy Preview	https://deploy-preview-122--thingweb.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 82 (🟢 up 3 from production) Accessibility: 95 (no change from production) Best Practices: 92 (no change from production) SEO: 92 (no change from production) PWA: - View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[egekorkan]

looks good but one question: should we commit API.md here or just keep it in the source?

[relu91]

Nice! a couple of questions before moving on:

• It seems that we changed the structure (Docs -> node-wot -> API to Docs -> API), we should configure the plugin to have different folders for different repositories (I guess you can just add an entry for each right?)
• How to handle versioning? if it is still something to figure out that's ok
• Since it is duplicated content, I would like to gitignore the pulled content from remote repositories (if possible)
• How would the release process look like? Should we manually trigger a release every time a doc is updated in the remote repository?

[egekorkan]

@relu91 the "plugin" is a rather stupid one :D I think we can just do some bash scripts and wget instead of this. There is no real automation, versioning etc. at the moment. Some concrete answers:

Since it is duplicated content, I would like to gitignore the pulled content from remote repositories (if possible)

I agree.

How would the release process look like? Should we manually trigger a release every time a doc is updated in the remote repository?

Currently, each time the page is built, the remote documents are pulled.

How to handle versioning? if it is still something to figure out that's ok

A solution, without reading anything, would be to version the documents in the remote repositories and add different download targets in the config here. Looking at https://docusaurus.io/docs/versioning we should simply do something like that.

[relu91]

Currently, each time the page is built, the remote documents are pulled.

That's ok for now.

A solution, without reading anything, would be to version the documents in the remote repositories and add different download targets in the config here. Looking at https://docusaurus.io/docs/versioning we should simply do something like that.

Good, we can start organizing it for node-wot.

[relu91]

I think the last step is to .gitignore files pulled with the docusaurus-plugin-remote-content and we are good to go.

[SergioCasCeb]

@relu91 , would you prefer to ignore the API.md file only, or should we ignore everything in the docs folder?

[relu91]

I think given that we settled to trust completely what is coming from the target repository we can ignore the whole folder. Then in the future, we can host a docs folder in node-wot, to be carried over and have a 1-1 mapping. Therefore, in node-wot we will put also configuration files for docusourus. @egekorkan what do you think?

[egekorkan]

I agree that the structure and content should come from node-wot repository. However, what docusaurus files you want to put there @relu91 ?

EDIT: We can ignore the whole folder :)

[relu91]

However, what docusaurus files you want to put there @relu91

I don't know, but reading https://docusaurus.io/docs/versioning I saw that you can also configure the sidebar with some json... I was thinking about that.

EDIT: We can ignore the whole folder :)

Good.

[SergioCasCeb]

The entire docs folder should now be ignored.

For future docs organization, if you want to put documentation in a specific folder (like a "node-wot"), just remember to add a category.json file. This ensures the sidebar has the right name and position. Here’s an example of what it should look like:

{
  "label": "node-wot",
  "position": 2,
  "link": {
    "type": "generated-index"
  }
}

[SergioCasCeb]

This should work now.
Since there isn't a category.json file to be copied over and we are ignoring everything in the docs folder, there is no manual way to add it. For now, this should not cause an issue, but later on, once more documentation is added, these files might be necessary to properly name and organize the sidebars.

[SergioCasCeb]

Also having the _category_.json file helps to create the preview when clicking on the parent folder. @relu91 @egekorkan

If we want to keep this, we can either:

• Manually create the folders and _category_.json files and make sure they're not in .gitignore.
• Keep the documentation from each repository inside a dedicated folder that already includes the _category_.json file.

[egekorkan]

Keep the documentation from each repository inside a dedicated folder that already includes the category.json file.

I think we should go with this direction in the repositories.

EDIT: However, we should make sure that the value of position is not conflicting between repositories