Skip to content

Set private=true in package.json to prevent accidental publishes to n… - #3

Merged
SilanHe merged 1 commit into
developmentfrom
dev-hsilan
Sep 3, 2025
Merged

SilanHe merged 1 commit into
developmentfrom
dev-hsilan

Conversation

@SilanHe

@SilanHe SilanHe commented Sep 2, 2025

Copy link
Copy Markdown
Contributor

…pm registry

Issue #, if available:

Description of changes: Set "private": true in package.json to prevent accidental publishes to npm registry

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@bchampp

bchampp commented Sep 3, 2025

Copy link
Copy Markdown
Member

LGTM!

@SilanHe
SilanHe merged commit 4946566 into development Sep 3, 2025
1 check passed
@SilanHe
SilanHe deleted the dev-hsilan branch September 3, 2025 17:02
ParidelPooya added a commit that referenced this pull request Aug 2, 2026
Review items 3, 4, 5, plus two from the closing list.

First, a note on approach. All three dag items are real — reproduced with `group`
as the control, which gets both the deps shim and the onError try/catch and is
correct. But none can be FIXED without deciding runtime API that does not exist
yet: a map iteratee is `(ctx, item, index)` and a parallel branch is `(ctx)`,
signatures inherited from the SDK's existing map/parallel, so there is nowhere to
bind deps without inventing a parameter. Guessing would replace a silently wrong
answer with a differently wrong one that looks authoritative.

So these now REFUSE at codegen time, consistent with the dag gate. Nobody can
generate code that runs and quietly does the wrong thing, and whoever lands the
runtime has to make the call explicitly and delete the guards.

#3 map iteratee / parallel branch referencing an upstream result: the reviewer's
reading is exactly right. `return Up;` compiled and handed back the TaskHandle.
The shim is injected only into map's ITEMS closure, and parallel gets none at all.
Now refused, with a test asserting group still binds `const Up = deps["Up"]` so
the guard cannot be mistaken for a blanket ban.

#4 Confirmed all four arms, dagContainer included — only dagClosureBody emits the
try/catch and these bypass it, so a dag workflow failed where the linear
equivalent recovers. dagContainer honouring runIf but not onError is what makes it
look accidental. Not uniformly fixable: a wait has no closure to wrap, and a
dagContainer's callback only REGISTERS child tasks, so a try/catch there would
catch registration rather than execution errors and give false confidence. All
four refuse.

#5 Confirmed. `dag.wait("W", [Up], { seconds: Up.s })` evaluates in the
surrounding scope where Up is the handle, so the duration was undefined; the
linear path works because there the name holds the value. No deps closure exists
to inject into, so refused.

From the closing list:
  - process.abort()/process.exit() are now neutered in the dry-run worker.
    Availability only, as noted, but abort takes down the whole extension host and
    it was cheap. Verified the host survives both.
  - npm.cmd on Windows (awsSdkReflect.ts): execFile cannot run the shell script
    shim, so this was ENOENT on Windows.

10 new tests. cdk 267, insight-vscode 413, visual-workflow-model 61,
webview-ui 91.
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