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(compiler-cli): ensure that ngcc does not write a lock-file into node_modules package directories #44228
fix(compiler-cli): ensure that ngcc does not write a lock-file into node_modules package directories #44228
Conversation
const moduleConstructor: any = module.constructor; | ||
const originalResolveFileName = moduleConstructor._resolveFilename; | ||
spyOn<any>(moduleConstructor, '_resolveFilename').and.callFake(function(request: string) { | ||
if (request === '@angular/compiler-cli/package.json') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can use a ternary here!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could...
…les package directories When executing, ngcc writes a lock-file that is used to coordinate multiple concurrent instances of ngcc. Previously, this file was written at `node_modules/@angular/compiler-cli/ngcc`, or similar depending upon the bundling of the package. But this causes problems for setups where `node_modules` package directories are expected to be read-only. Now, the lock-file is written as `.ngcc_lock_file` into the top of the `node_modules`, which is an acceptable place to store transient files. This change should help to unblock use of tools like pnpm and lerna, which can use symlinks to readonly package directories.
…de_modules package directories
This PR was merged into the repository by commit 24b6353. |
…les package directories (#44228) When executing, ngcc writes a lock-file that is used to coordinate multiple concurrent instances of ngcc. Previously, this file was written at `node_modules/@angular/compiler-cli/ngcc`, or similar depending upon the bundling of the package. But this causes problems for setups where `node_modules` package directories are expected to be read-only. Now, the lock-file is written as `.ngcc_lock_file` into the top of the `node_modules`, which is an acceptable place to store transient files. This change should help to unblock use of tools like pnpm and lerna, which can use symlinks to readonly package directories. PR Close #44228
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. |
…les package directories (angular#44228) When executing, ngcc writes a lock-file that is used to coordinate multiple concurrent instances of ngcc. Previously, this file was written at `node_modules/@angular/compiler-cli/ngcc`, or similar depending upon the bundling of the package. But this causes problems for setups where `node_modules` package directories are expected to be read-only. Now, the lock-file is written as `.ngcc_lock_file` into the top of the `node_modules`, which is an acceptable place to store transient files. This change should help to unblock use of tools like pnpm and lerna, which can use symlinks to readonly package directories. PR Close angular#44228
When executing, ngcc writes a lock-file that is used to coordinate multiple concurrent instances of ngcc.
Previously, this file was written at
node_modules/@angular/compiler-cli/ngcc
, or similar depending upon the bundling of the package.But this causes problems for setups where
node_modules
package directories are expected to be read-only.Now, the lock-file is written as
.ngcc_lock_file
into the top of thenode_modules
, which is an acceptable place to store transient files.This change should help to unblock use of tools like pnpm and lerna, which can use symlinks to readonly package directories.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information
The text was updated successfully, but these errors were encountered: