Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docusaurus documentation site #74

Merged
merged 18 commits into from
Jan 12, 2022

Conversation

mongodben
Copy link
Contributor

add Docusaurus documentation site to project.

staging version of site: https://mongodben.github.io/Bluehawk

docs/README.md Outdated Show resolved Hide resolved
docs/README.md Outdated Show resolved Hide resolved
docs/README.md Show resolved Hide resolved
docs/README.md Outdated Show resolved Hide resolved
@@ -10,13 +10,10 @@
"strict": true,
"declaration": true,
"declarationMap": true,
"resolveJsonModule": true
"resolveJsonModule": true,
"useUnknownInCatchVariables": false
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this related?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea it's required for the typedoc docusaurus plugin to work.

if this flag isn't enabled, the plugin throws the following error when it runs:

error msg
Error: ../src/bluehawk/actions/copy.ts:29:62 - error TS2571: Object is of type 'unknown'.

29     const message = `Could not load stats for ${rootPath}: ${error.message}`;
                                                                ~~~~~

Error: ../src/bluehawk/actions/copy.ts:50:76 - error TS2571: Object is of type 'unknown'.

50       const message = `Failed to copy file ${filePath} to ${targetPath}: ${error.message}`;
                                                                              ~~~~~

Error: ../src/bluehawk/actions/copy.ts:111:100 - error TS2571: Object is of type 'unknown'.

111       const message = `Failed to write file ${targetPath} (based on ${parseResult.source.path}): ${error.message}`;
                                                                                                       ~~~~~

Error: ../src/bluehawk/actions/snip.ts:162:95 - error TS2571: Object is of type 'unknown'.

162       const message = `Failed to write ${targetPath} (based on ${parseResult.source.path}): ${error.message}`;
                                                                                                  ~~~~~

Error: ../src/bluehawk/bluehawk.ts:132:3 - error TS2571: Object is of type 'unknown'.

132 ${e.stack}
      ~

Error: ../src/bluehawk/bluehawk.ts:162:65 - error TS2571: Object is of type 'unknown'.

162         `falling back to plaintext parser for ${source.path}: ${error.message}`
                                                                    ~~~~~

Error: ../src/bluehawk/parser/visitor/makeCstVisitor.ts:244:37 - error TS2345: Argument of type 'unknown' is not assignable to parameter of type 'Error'.

244             jsonErrorToVisitorError(error, json, {
                                        ~~~~~

Error: ../src/cli/cli.ts:45:7 - error TS2571: Object is of type 'unknown'.

45       error.message = `Plugin '${path}' register() failed with error: ${error.message}`;
         ~~~~~

Error: ../src/cli/cli.ts:45:73 - error TS2571: Object is of type 'unknown'.

45       error.message = `Plugin '${path}' register() failed with error: ${error.message}`;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like these are errors in our (Bluehawk) code. Do you think we could update bh to cast the unkown errors instead (in the future perhaps)?

unknown is technically more correct and in general I think it's best that we stick as closely as possible to default/strict typescript.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't really understand the question, could you expand a bit?

Copy link
Contributor

@nlarew nlarew Jan 7, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm mainly interested if the errors you see with { useUnknownInCatchVariables: true } are something we could fix by updating the bluehawk source code. If so, I think we should fix them (i.e. what they do on this page) and then enable useUnknownInCatchVariables here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I fixed this on our end in #76

Once we merge that can we try docusaurus with useUnknownInCatchVariables set to true?

docs/README.md Outdated Show resolved Hide resolved
Copy link
Contributor

@nlarew nlarew left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The /docs/docs/* directory structure feels a bit weird to me. Is this a docusaurus convention? Could we rename to something like /docs/content/* or something else that makes sense but reduces repetition?

@mongodben
Copy link
Contributor Author

@nlarew having the subdirectory named docs is docusaurus convention. and i'd advocate we keep it as such. but we could certainly name the parent directory something else. so it's like OTHER_NAME/docs/*. open to ideas 😀

mongodben and others added 7 commits January 6, 2022 17:44
use patch-package to make tweak to chevrotain so that it renders properly with the docusaurus typedoc plugin.

added npm postinstall script as well so that patch package runs after installing node modules.
Co-authored-by: Chris Bush <chris.bush@10gen.com>
README.md Show resolved Hide resolved
@@ -0,0 +1,198 @@
---
id: "Bluehawk"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do these files actually need to be committed or can they be added to gitignore and just generated on the fly (during github action)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think .gitignore-ing them would make sense. will make that change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

package.json Show resolved Hide resolved
@@ -1,27 +0,0 @@
name: Generate Docs and Publish to GitHub Pages
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a nitpick but I find this was a much better name than just "deploy.yml". Deploy what? Maybe "deploy-docs.yaml"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense to me. renaming

@mongodben mongodben merged commit 61a360f into mongodb-university:main Jan 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants