feat: cloudscape frontend#1606
Conversation
megha-narayanan
temporarily deployed
to
automation
GitHub Actions
Inactive
megha-narayanan
requested a deployment
to
integ-approval
GitHub Actions
Waiting
|
Frontend: |
megha-narayanan
requested a deployment
to
integ-approval
GitHub Actions
Waiting
Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
aws-cdk-automation
requested a deployment
to
integ-approval
GitHub Actions
Waiting
Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
aws-cdk-automation
requested a deployment
to
integ-approval
GitHub Actions
Waiting
…affold) # Conflicts: # .projenrc.ts # packages/@aws-cdk/cdk-explorer/package.json # yarn.lock
megha-narayanan
requested a deployment
to
integ-approval
GitHub Actions
Waiting
Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
aws-cdk-automation
requested a deployment
to
integ-approval
GitHub Actions
Waiting
There was a problem hiding this comment.
Can you explain a bit why you are doing this unique path to bundling the code for the web explorer? Is it because of the frontend code?
There was a problem hiding this comment.
yep, it's driven entirely by the frontend, and there are two separate problems this handles:
First, the frontend is browser code, not server code, so it can't go through the normal per-file tsc compile. esbuild bundles frontend/index.tsx into a single bundle.js/bundle.css. esbuild only transpiles, so we typecheck the frontend separately with tsc --noEmit -p tsconfig.frontend.json
Second, getting those assets into the published CLI, which is the more complicated part. The aws-cdk CLI ships as one bundle that only includes what's reachable through the require() graph. Assets served off disk via express.static/sendFile are invisible to the bundler and get dropped from the npm tarball, so the explorer would 404 in a real install even though it works from source. To avoid that, the script writes the built assets into lib/web/web-assets.generated.json, and web-assets.ts does a static require('./web-assets.generated.json'). That require carries the bytes into the CLI bundle, and the server serves them from memory rather than disk.
| import { FilePane } from './components/FilePane'; | ||
|
|
||
| /** Web explorer shell: Resource Tree (left), two file panes, Violations (bottom). Tree/violations are placeholders until the cloud-assembly reader is wired in. */ | ||
| export function App(): JSX.Element { |
There was a problem hiding this comment.
Is there a way to make this more flexible in the future so customers can resize/rearrange their panels?
There was a problem hiding this comment.
TL; DR: Kind of, but the UI looks way worse. I played around with this for a few hours yesterday. In the next PR, I have code that makes the construct tree resizable horizontally. In my RFC, i had re-arrangable panes as a stretch goal. With cloudscape I've actually been finding that pretty hard, so my plan was to leave it as a stretch goal for now, lmk if you think its important enough to devote time to now.
| * `root` is expected to be absolute. A leading `/` on `requested` is stripped so | ||
| * absolute-looking inputs cannot jump to the filesystem root. | ||
| */ | ||
| export function resolveWithinRoot(root: string, requested: string): string | undefined { |
There was a problem hiding this comment.
will this work for Windows file paths?
There was a problem hiding this comment.
Yep, all path manipulation goes through Node's path module, which is platform aware. Traversal via ..\ and drive-absolute inputs like C:\Windows get rejected by the same isInside check.
Addresses review feedback on PR aws#1606. CI runs on Linux only, so the new describe block reloads safe-path with path mocked to path.win32 to exercise real Windows behavior (drive letters, backslash separators, drive and UNC escape rejection) on the Linux runner.
megha-narayanan
requested a deployment
to
integ-approval
GitHub Actions
Waiting
3 participants
Builds the
cdk exploreweb explorer UI, with a React + Cloudscape single-page app is served by the existingExpress server, alongside file-serving API endpoints.
lib/web/):GET /api/health,GET /api/files?dir=,GET /api/file?path=,frontend/): CloudscapeContentLayoutwith four regions. The two center/right panes are functional server-backed file viewers (browse + view). Header shows a "last updated" placeholder.frontend/is compiled by esbuild (separatetsconfig.frontend.json, kept off the Nodetscpath) inpost-compile, then embedded intoweb-assets.generated.jsonand served from memory so it travels in thebundled CLI.
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license