Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(ngcc): correctly resolve UMD dependencies #44381

Closed

Conversation

gkalpak
Copy link
Member

@gkalpak gkalpak commented Dec 5, 2021

Previously, when processing UMD, ngcc assumed that the exports argument of the CommonJS factory call (if present) would be the first argument of the call. This is generally true for the supported UMD formats, but can change if ngcc prepends more imports (and thus factory arguments) while processing the module. This could lead to errors when trying to collect dependencies of an already processed module.
(This was accidentally broken in #44245 (commit 2bc3522).)

This commit fixes it by not making any assumptions about the position of an exports argument in the CommonJS factory call.

Fixes #44380.

Previously, when processing UMD, ngcc assumed that the `exports`
argument of the CommonJS factory call (if present) would be the first
argument of the call. This is generally true for the supported UMD
formats, but can change if ngcc prepends more imports (and thus factory
arguments) while processing the module. This could lead to errors when
trying to collect dependencies of an already processed module.
(This was accidentally broken in angular#44245 (commit 2bc3522).)

This commit fixes it by not making any assumptions about the position of
an `exports` argument in the CommonJS factory call.

Fixes angular#44380
@gkalpak gkalpak added type: bug/fix target: patch This PR is targeted for the next patch release comp: ngcc labels Dec 5, 2021
@google-cla google-cla bot added the cla: yes label Dec 5, 2021
@ngbot ngbot bot added this to the Backlog milestone Dec 5, 2021
@mary-poppins
Copy link

You can preview 86d5c2e at https://pr44381-86d5c2e.ngbuilds.io/.

@gkalpak gkalpak marked this pull request as ready for review December 5, 2021 21:27
@gkalpak gkalpak added the action: review The PR is still awaiting reviews from at least one requested reviewer label Dec 5, 2021
@gkalpak gkalpak requested a review from JoostK December 5, 2021 21:27
@mary-poppins
Copy link

You can preview 74d122d at https://pr44381-74d122d.ngbuilds.io/.

@gkalpak gkalpak added action: merge The PR is ready for merge by the caretaker and removed action: review The PR is still awaiting reviews from at least one requested reviewer labels Dec 6, 2021
@alxhub
Copy link
Member

alxhub commented Dec 7, 2021

This PR was merged into the repository by commit 4126591.

@alxhub alxhub closed this in 4126591 Dec 7, 2021
alxhub pushed a commit that referenced this pull request Dec 7, 2021
Previously, when processing UMD, ngcc assumed that the `exports`
argument of the CommonJS factory call (if present) would be the first
argument of the call. This is generally true for the supported UMD
formats, but can change if ngcc prepends more imports (and thus factory
arguments) while processing the module. This could lead to errors when
trying to collect dependencies of an already processed module.
(This was accidentally broken in #44245 (commit 2bc3522).)

This commit fixes it by not making any assumptions about the position of
an `exports` argument in the CommonJS factory call.

Fixes #44380

PR Close #44381
@gkalpak gkalpak deleted the fix-ngcc-umd-preceeding-imports branch December 7, 2021 15:59
dimakuba pushed a commit to dimakuba/angular that referenced this pull request Dec 28, 2021
Previously, when processing UMD, ngcc assumed that the `exports`
argument of the CommonJS factory call (if present) would be the first
argument of the call. This is generally true for the supported UMD
formats, but can change if ngcc prepends more imports (and thus factory
arguments) while processing the module. This could lead to errors when
trying to collect dependencies of an already processed module.
(This was accidentally broken in angular#44245 (commit 2bc3522).)

This commit fixes it by not making any assumptions about the position of
an `exports` argument in the CommonJS factory call.

Fixes angular#44380

PR Close angular#44381
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Jan 7, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker cla: yes target: patch This PR is targeted for the next patch release type: bug/fix
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Error: Argument at index 2 of UMD factory call is not a require call with a single string argument
4 participants