fix(di): share the injection context across duplicated CLI copies - #6121
Closed
edusperoni wants to merge 1 commit into
Closed
fix(di): share the injection context across duplicated CLI copies#6121edusperoni wants to merge 1 commit into
edusperoni wants to merge 1 commit into
Conversation
The context slot was module-local, so a hook or extension module that resolves a different copy of the CLI than the one running (a nested nativescript install, or a project-local copy under a globally-run CLI) got a dead slot and inject() threw despite being synchronously inside a valid context. The slot now lives on globalThis under a Symbol.for key, and a copy serving inject() through a frame it did not set warns once, naming its path - the duplicated copy works but loads the CLI twice, and peerDependencies avoid it. The second-copy test loads a genuinely separate module instance: inject.js has no runtime imports, so a copied file is the real duplicated-copy situation.
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Collaborator
Author
|
Landed directly on main as b52b8e0. |
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
1 participant
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.
PR Checklist
What is the current behavior?
The injection context (
inject()'s hiddencurrentslot) is a module-local variable. Node caches modules per resolved path, so when a hook or extension module resolves a different copy of the CLI than the one running — a nestednativescriptinstall in an extension's tree, or a project-local copy under a globally-run CLI — that copy'sinject()reads its own dead slot and throws "inject() can only be called from an injection context", even though the author is synchronously insiderun()in a perfectly valid context. Verified in review with a realistic duplicated-copy install; it breaks the documented flagship examples of the stacked API PRs.What is the new behavior?
The context lives on
globalThisunder aSymbol.forkey, so every loaded copy shares one slot — in the single-copy world the behavior is byte-identical. When a copy servesinject()through a frame it did not set (i.e. a duplicated copy is in play), it warns once, naming its own path and pointing at the fix: duplicated copies work but load the CLI twice;peerDependencyonnativescriptlets the running copy be shared. This keeps the ecosystem nudged toward the single-copy/local-install direction while making the documented API true in every install layout that exists today.Tests include a genuine second-copy scenario:
inject.jshas no runtime imports, so a copied file loaded from another path is a real second module instance — it resolves through the running copy's context and produces exactly one warning.Full suite green; no behavior change when a single copy is loaded.