Loading workspace insights... Statistics interval
7 days30 daysLatest CI Pipeline Executions
06bffdb0 feat(misc)!: remove deprecated js option from component generators (#35616)
## Current Behavior
The `@nx/react`, `@nx/react-native`, and `@nx/expo` component generators
expose a `--js` option to generate JavaScript files instead of
TypeScript. The option was deprecated in #29111 (targeted for removal in
Nx v21) in favor of including the file extension directly in the `path`
argument:
```sh
nx g @nx/react:component mylib/src/lib/foo.jsx
```
We are now on Nx v23 — past the deprecation window — but the option
still exists.
## Expected Behavior
The `--js` option is removed from the component generators in
`@nx/react`, `@nx/react-native`, and `@nx/expo`. Users include the
desired file extension directly in the `path` argument; the path's
extension drives whether `.tsx`, `.jsx`, `.ts`, or `.js` files are
generated. When no extension is provided, the generators default to
`.tsx`, matching prior behavior.
The library generators in those three packages still keep their own
`--js` option (out of scope for this change). Internally they now encode
`.js` into the `path` they pass to the component generator instead of
forwarding the now-removed `js` flag.
### BREAKING CHANGE
The `--js` option has been removed from:
- `@nx/react:component`
- `@nx/react-native:component`
- `@nx/expo:component`
Migration: include the file extension in the `path` argument, e.g. `nx g
@nx/react:component mylib/src/lib/foo.jsx`.
## Related Issue(s)
Linear:
[NXC-3665](https://linear.app/nxdev/issue/NXC-3665/common-remove-js-option-from-component-generators) 643bde9a fix(core): allow `nx mcp` to run outside of an Nx workspace (#35655)
## Current Behavior
Running `nx mcp` from a directory that is not part of an Nx workspace
prints the workspace-not-found banner and exits with code 1, **before**
the `mcp` command's handler is ever invoked.
This breaks MCP clients (e.g. Codex CLI) that spawn `npx nx mcp` over
stdio JSON-RPC. The banner is written to **stdout**, corrupting the
JSON-RPC stream, and the process exits before the MCP `initialize`
handshake completes. Clients surface this as:
> MCP startup failed: handshaking with MCP server failed: connection
closed: initialize response
Reproduction:
```
$ cd /tmp/empty-dir
$ npx nx mcp
NX The current directory isn't part of an Nx workspace.
...
# exit 1, written to stdout
```
## Expected Behavior
`nx mcp` should be able to run outside of an Nx workspace, the same way
`nx init`, `nx configure-ai-agents`, and `nx graph` already can. The
`mcp` command delegates entirely to `nx-mcp@latest` via the package
manager's `dlx`, and `nx-mcp` already handles non-workspace directories
correctly.
## Root Cause
`packages/nx/bin/nx.ts` contains a hard-coded allow-list of commands
that bypass the `!workspace → handleNoWorkspace()` guard. The list
currently includes `new`, `_migrate`, `init`, `configure-ai-agents`, and
`graph && !workspace`. The `mcp` command was added to the command
registry in `nx-commands.ts` but was never added to this allow-list, so
execution hits the workspace check first and exits before reaching
`mcpHandler`.
## Fix
Add `'mcp'` to the allow-list in `packages/nx/bin/nx.ts`. The handler
uses `workspaceRoot` only as the `cwd` for spawning `nx-mcp@latest`, and
`workspaceRoot` already gracefully falls back to `process.cwd()` when no
workspace is detected.
```diff
process.argv[2] === '_migrate' ||
process.argv[2] === 'init' ||
process.argv[2] === 'configure-ai-agents' ||
+ process.argv[2] === 'mcp' ||
(process.argv[2] === 'graph' && !workspace)
```
## Related Issue(s)
Fixes: discovered via nx-console / Codex CLI MCP integration — `nx mcp`
configured as an MCP server in a non-workspace cwd fails to start.
<!-- polygraph-session-start -->
---
[View session information
↗](https://snapshot.app.trypolygraph.com/orgs/69cdc268b6aa527e4129c2b4/sessions/nx-mcp-error-in-non-repo-path-e0a28-a87e5654)
<!-- polygraph-session-end -->
---------
Co-authored-by: Max Kless <maxk@nrwl.io>
Co-authored-by: nx-cloud[bot] <71083854+nx-cloud[bot]@users.noreply.github.com> 90f675e7 fix(core): correct TUI sidebar viewport height off-by-one (#34682)
_This PR description was generated by Amp._
## Current Behavior
The TUI task sidebar appears scrolled down by one entry on render,
hiding the first continuous task from view.
<img width="1167" height="829" alt="Screenshot 2026-03-03 at 10 56 09
AM"
src="https://github.com/user-attachments/assets/83421f89-3be9-4f80-80b2-c57bd0c2c161"
/>
Here you can see that `watch-deps` is running in addition to `dev`.
## Expected Behavior
All continuous tasks should be visible in the sidebar without any
initial scroll offset.
## Related Issue(s)
N/A (discovered via visual inspection)
## Details
The viewport height calculation in `tasks_list.rs` subtracted 4 rows for
header overhead, but the actual overhead is only 3 rows:
1. `top_margin` (1 row)
2. Header content (1 row)
3. Spacing row (1 row)
This off-by-one caused the viewport to be 1 row too small, making the
task list appear scrolled down by one entry on initial render.
### Changes
1. **Unified overhead constant**: Introduced `TABLE_HEADER_OVERHEAD_ROWS
= 3` and `SCROLLBAR_Y_OFFSET = 2`, replacing scattered hardcoded values.
The scrollbar y-offset is 2 (not 3) because the scrollbar visually spans
from the spacing row downward, while the viewport only counts content
rows.
2. **Stale scroll correction**: Added logic in `set_viewport_height` to
reset `scroll_offset` to 0 when the viewport grows from a small
placeholder size (≤ 5) to the real terminal size, provided the selected
item is still visible from the top. This prevents stale scroll positions
set during initialization from hiding top items.
3. **Regression tests**: Added
`test_viewport_growth_resets_stale_scroll_offset` and
`test_viewport_growth_preserves_scroll_when_selection_not_visible` to
cover the stale scroll correction.
4. **Snapshot updates**: 14 snapshot files updated to reflect one
additional visible row.
### History
The `4` originated in commit `6541751a` (James Henry, Apr 2025) with the
comment "Reserve space for pagination and borders." However, the table
had no borders (`Block::default()` without `Borders`), and pagination
lived in its own layout chunk. The `4` was a rough estimate that was
never precisely derived from the actual header structure. When scrolling
replaced pagination in commit `1782e8c7` (Leosvel Perez Espinola, Sep
2025), the value was carried forward unchanged. The same commit also
introduced a separate `header_and_spacing_rows = 2` for the scrollbar
y-offset, confirming these values were set independently without unified
accounting.
Also documents the `copy-built-package` script in `AGENTS.md` for
AI-assisted development workflows.
Co-authored-by: Amp <amp@ampcode.com> 90f675e7 fix(core): correct TUI sidebar viewport height off-by-one (#34682)
_This PR description was generated by Amp._
## Current Behavior
The TUI task sidebar appears scrolled down by one entry on render,
hiding the first continuous task from view.
<img width="1167" height="829" alt="Screenshot 2026-03-03 at 10 56 09
AM"
src="https://github.com/user-attachments/assets/83421f89-3be9-4f80-80b2-c57bd0c2c161"
/>
Here you can see that `watch-deps` is running in addition to `dev`.
## Expected Behavior
All continuous tasks should be visible in the sidebar without any
initial scroll offset.
## Related Issue(s)
N/A (discovered via visual inspection)
## Details
The viewport height calculation in `tasks_list.rs` subtracted 4 rows for
header overhead, but the actual overhead is only 3 rows:
1. `top_margin` (1 row)
2. Header content (1 row)
3. Spacing row (1 row)
This off-by-one caused the viewport to be 1 row too small, making the
task list appear scrolled down by one entry on initial render.
### Changes
1. **Unified overhead constant**: Introduced `TABLE_HEADER_OVERHEAD_ROWS
= 3` and `SCROLLBAR_Y_OFFSET = 2`, replacing scattered hardcoded values.
The scrollbar y-offset is 2 (not 3) because the scrollbar visually spans
from the spacing row downward, while the viewport only counts content
rows.
2. **Stale scroll correction**: Added logic in `set_viewport_height` to
reset `scroll_offset` to 0 when the viewport grows from a small
placeholder size (≤ 5) to the real terminal size, provided the selected
item is still visible from the top. This prevents stale scroll positions
set during initialization from hiding top items.
3. **Regression tests**: Added
`test_viewport_growth_resets_stale_scroll_offset` and
`test_viewport_growth_preserves_scroll_when_selection_not_visible` to
cover the stale scroll correction.
4. **Snapshot updates**: 14 snapshot files updated to reflect one
additional visible row.
### History
The `4` originated in commit `6541751a` (James Henry, Apr 2025) with the
comment "Reserve space for pagination and borders." However, the table
had no borders (`Block::default()` without `Borders`), and pagination
lived in its own layout chunk. The `4` was a rough estimate that was
never precisely derived from the actual header structure. When scrolling
replaced pagination in commit `1782e8c7` (Leosvel Perez Espinola, Sep
2025), the value was carried forward unchanged. The same commit also
introduced a separate `header_and_spacing_rows = 2` for the scrollbar
y-offset, confirming these values were set independently without unified
accounting.
Also documents the `copy-built-package` script in `AGENTS.md` for
AI-assisted development workflows.
Co-authored-by: Amp <amp@ampcode.com> 90f675e7 fix(core): correct TUI sidebar viewport height off-by-one (#34682)
_This PR description was generated by Amp._
## Current Behavior
The TUI task sidebar appears scrolled down by one entry on render,
hiding the first continuous task from view.
<img width="1167" height="829" alt="Screenshot 2026-03-03 at 10 56 09
AM"
src="https://github.com/user-attachments/assets/83421f89-3be9-4f80-80b2-c57bd0c2c161"
/>
Here you can see that `watch-deps` is running in addition to `dev`.
## Expected Behavior
All continuous tasks should be visible in the sidebar without any
initial scroll offset.
## Related Issue(s)
N/A (discovered via visual inspection)
## Details
The viewport height calculation in `tasks_list.rs` subtracted 4 rows for
header overhead, but the actual overhead is only 3 rows:
1. `top_margin` (1 row)
2. Header content (1 row)
3. Spacing row (1 row)
This off-by-one caused the viewport to be 1 row too small, making the
task list appear scrolled down by one entry on initial render.
### Changes
1. **Unified overhead constant**: Introduced `TABLE_HEADER_OVERHEAD_ROWS
= 3` and `SCROLLBAR_Y_OFFSET = 2`, replacing scattered hardcoded values.
The scrollbar y-offset is 2 (not 3) because the scrollbar visually spans
from the spacing row downward, while the viewport only counts content
rows.
2. **Stale scroll correction**: Added logic in `set_viewport_height` to
reset `scroll_offset` to 0 when the viewport grows from a small
placeholder size (≤ 5) to the real terminal size, provided the selected
item is still visible from the top. This prevents stale scroll positions
set during initialization from hiding top items.
3. **Regression tests**: Added
`test_viewport_growth_resets_stale_scroll_offset` and
`test_viewport_growth_preserves_scroll_when_selection_not_visible` to
cover the stale scroll correction.
4. **Snapshot updates**: 14 snapshot files updated to reflect one
additional visible row.
### History
The `4` originated in commit `6541751a` (James Henry, Apr 2025) with the
comment "Reserve space for pagination and borders." However, the table
had no borders (`Block::default()` without `Borders`), and pagination
lived in its own layout chunk. The `4` was a rough estimate that was
never precisely derived from the actual header structure. When scrolling
replaced pagination in commit `1782e8c7` (Leosvel Perez Espinola, Sep
2025), the value was carried forward unchanged. The same commit also
introduced a separate `header_and_spacing_rows = 2` for the scrollbar
y-offset, confirming these values were set independently without unified
accounting.
Also documents the `copy-built-package` script in `AGENTS.md` for
AI-assisted development workflows.
Co-authored-by: Amp <amp@ampcode.com>