build: remove ngcc postinstall patch in favor of separate script #18355
Conversation
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
googlebot
added
the
cla: yes
devversion
added
P2
|
Marking as P2 since it is needed for a framework PR that is blocked on this. angular/angular#35079 |
mmalerba
approved these changes
Jan 31, 2020
petebacondarwin
added a commit
to petebacondarwin/angular
that referenced
this pull request
Jan 31, 2020
Disabling this job until the fix at angular/components#18355 or similar lands.
mhevery
pushed a commit
to angular/angular
that referenced
this pull request
Feb 1, 2020
Disabling this job until the fix at angular/components#18355 or similar lands. PR Close #35079
mhevery
pushed a commit
to angular/angular
that referenced
this pull request
Feb 1, 2020
Disabling this job until the fix at angular/components#18355 or similar lands. PR Close #35079
Currently we always patch `ngcc` as part of a postinstall patch. This is because Ngcc does not overwrite the `main` field of processed packages. Though, since we want to run `nodejs_binary`/`nodejs_test` targets with Ivy, we need to either have custom module resolution, or just need to update the `package.json` files to point to the NGCC processed bundles. Implementing a custom module resolution for each of these target seems rather incovenient and less reliable. Instead, we just ensure the `package.json` files point to the right files. Currently we achieve this by patching ngcc to always update the `main` property. This patch is prone to upstream ngcc changes, so we move it into a separate script that just runs _after_ ngcc, and updates the `package.json` files. The benfit of this is that `ngcc` doesn't need to be patched, and upstream ngcc changes are not likely breaking the components repo unit test (as seen in: https://circleci.com/gh/angular/angular/608106).
devversion
force-pushed
the
build/more-reliable-ngcc-field-update
branch
from
405c9e1 to
34f4d91
Compare
mmalerba
pushed a commit
that referenced
this pull request
Feb 5, 2020
) Currently we always patch `ngcc` as part of a postinstall patch. This is because Ngcc does not overwrite the `main` field of processed packages. Though, since we want to run `nodejs_binary`/`nodejs_test` targets with Ivy, we need to either have custom module resolution, or just need to update the `package.json` files to point to the NGCC processed bundles. Implementing a custom module resolution for each of these target seems rather incovenient and less reliable. Instead, we just ensure the `package.json` files point to the right files. Currently we achieve this by patching ngcc to always update the `main` property. This patch is prone to upstream ngcc changes, so we move it into a separate script that just runs _after_ ngcc, and updates the `package.json` files. The benfit of this is that `ngcc` doesn't need to be patched, and upstream ngcc changes are not likely breaking the components repo unit test (as seen in: https://circleci.com/gh/angular/angular/608106).
yifange
pushed a commit
to yifange/components
that referenced
this pull request
Feb 6, 2020
…ular#18355) Currently we always patch `ngcc` as part of a postinstall patch. This is because Ngcc does not overwrite the `main` field of processed packages. Though, since we want to run `nodejs_binary`/`nodejs_test` targets with Ivy, we need to either have custom module resolution, or just need to update the `package.json` files to point to the NGCC processed bundles. Implementing a custom module resolution for each of these target seems rather incovenient and less reliable. Instead, we just ensure the `package.json` files point to the right files. Currently we achieve this by patching ngcc to always update the `main` property. This patch is prone to upstream ngcc changes, so we move it into a separate script that just runs _after_ ngcc, and updates the `package.json` files. The benfit of this is that `ngcc` doesn't need to be patched, and upstream ngcc changes are not likely breaking the components repo unit test (as seen in: https://circleci.com/gh/angular/angular/608106).
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Currently we always patch
ngccas part of a postinstall patch. This isbecause Ngcc does not overwrite the
mainfield of processed packages.Though, since we want to run
nodejs_binary/nodejs_testtargets withIvy, we need to either have custom module resolution, or just need to
update the
package.jsonfiles to point to the NGCC processed bundles.Implementing a custom module resolution for each of these target seems
rather incovenient and less reliable. Instead, we just ensure the
package.jsonfiles point to the right files.Currently we achieve this by patching ngcc to always update the
mainproperty. This patch is prone to upstream ngcc changes, so we move it
into a separate script that just runs after ngcc, and updates the
package.jsonfiles. The benfit of this is thatngccdoesn't need tobe patched, and upstream ngcc changes are not likely breaking the
components repo unit test (as seen in:
https://circleci.com/gh/angular/angular/608106).