Open
Conversation
Problem: `npm run build` generates lots of artifacts, many of them inside the source tree, but currently there is no way to remove them. Solution: add an npm script that clears the nx cache and removes generates files.
Problem: If there is an error during document generation, the error is printed, but document generation continues, failing later in the pipeline. Solution: Throw the error, making node exit with a non-zero error code, making nx abort the pipeline with a failure at the right location
Problem: For some reason, the `@nx/js:node` SILENTLY ABORTS the exectution after a timeout, WHITHOUT an error code. See https://github.com/nrwl/nx/blob/4377c8b00d2343058f7d4ebd572d18b559682b43/packages/js/src/executors/node/node.impl.ts#L109-L132 Solution: Use the `nx:run-commands` executor instead
…amles Problem: The docs-generator uses an (outdated) example for all referencable valuetypes. Solution: Get the example from an overridable valuetype method and update the default
Problem: Document generation crashes because `SheetRow` does not provide required documentation Solution: Override the required method and provide a custom example The previous commits make sure the pipeline actually crashes at the correct location, instead of failing silently or too late. This commit actually fixes the pipeline
jrentlez
added
bug
georg-schwarz
approved these changes
Mar 5, 2026
| "start": { | ||
| "executor": "@nx/js:node", | ||
| "dependsOn": ["generate-language-server"], | ||
| "executor": "nx:run-commands", |
Member
There was a problem hiding this comment.
Could you please add a comment here and say that this did not work with @nx/js:node and link the PR?
Comment on lines
+47
to
+66
| valuetype TableSchema { | ||
| tableColumn: ${name}; | ||
| } | ||
| transfrom tableRowParser { | ||
| from r oftype SheetRow; | ||
| to tableRow oftye TableSchema; | ||
|
|
||
| tableRow: { | ||
| tableColumn: as${capitalizedName} (r . "tableColumn"); | ||
| }; | ||
| } | ||
| block ExampleTableInterpreter oftype TableInterpreter { | ||
| header: true; | ||
| columns: TableSchema; | ||
| parseWith: tableRowParser; | ||
| }`.trim(), | ||
| description: | ||
| `A block of type \`TableInterpreter\` that interprets data in the column "columnName" as \`${name}\`. | ||
| `.trim(), | ||
| }, |
Member
There was a problem hiding this comment.
Would be cool to have a real example / close to a real use-case and not a dummy one
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR fixes the CI failure on main.
The fundamental problem is that
SheetRowdoes not overridegetUserDoc(), which causesnx run docs-generator:startto fail. This is only noticeable in the CI, because existing repos have a left-overbuiltin-value-types.mdin the source tree, which is used bynx build docsinstead.However, while working on this I discovered another issue:
nx run docs-generator:startstops before ever getting to the above failure, without any error log or error code. The exact stop location is very inconsistent. Unfortunately, I got on the wrong track here and spent quite some time looking intolangiumandchevrotainsource code, to try and figure out where exactly this crash originates.Long story short, this happens because nx stops the underlying
nodeprocess after a timeout, attempts to restart it, and then continues execution without any hint to the user.See the commit messages for more details.
I decided to fix both issues in one PR, because fixing only one issue would leave code we know to be erroneous in main.