-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
Getting EISDIR: illegal operation on a directory
when migrating from 8.x to 9.0
#18434
Getting EISDIR: illegal operation on a directory
when migrating from 8.x to 9.0
#18434
Comments
@paustint Thanks for the issue. I'm trying to reproduce this on my end. The I agree that it's unfortunate that there is not enough context in the error message. I wish there would be more that is printed out initially. Do you think that you would be to able to re-run the update? There isn't a good way for getting better error messages for
That would help a lot. Thanks! |
OK - I found out some possible useful information.
And that log shows this: [error] Error: EISDIR: illegal operation on a directory, read
at Object.readSync (fs.js:513:3)
at tryReadSync (fs.js:338:20)
at Object.readFileSync (fs.js:375:19)
at ComponentResourceCollector.resolveExternalStylesheet (/Users/foo/dev/node/foo/node_modules/@angular/cdk/schematics/update-tool/component-resource-collector.js:137:38)
at /Users/foo/dev/node/foo/node_modules/@angular/cdk/schematics/update-tool/index.js:87:50
at Array.forEach (<anonymous>)
at Object.runMigrationRules (/Users/foo/dev/node/foo/node_modules/@angular/cdk/schematics/update-tool/index.js:86:14)
at runMigration (/Users/foo/dev/node/foo/node_modules/@angular/cdk/schematics/ng-update/upgrade-rules/index.js:77:46)
at /Users/foo/dev/node/foo/node_modules/@angular/cdk/schematics/ng-update/upgrade-rules/index.js:80:37
at Array.forEach (<anonymous>)
at Object.<anonymous> (/Users/foo/dev/node/foo/node_modules/@angular/cdk/schematics/ng-update/upgrade-rules/index.js:80:24)
at Generator.next (<anonymous>)
at /Users/foo/dev/node/foo/node_modules/@angular/cdk/schematics/ng-update/upgrade-rules/index.js:14:71
at new Promise (<anonymous>)
at __awaiter (/Users/foo/dev/node/foo/node_modules/@angular/cdk/schematics/ng-update/upgrade-rules/index.js:10:12)
at /Users/foo/dev/node/foo/node_modules/@angular/cdk/schematics/ng-update/upgrade-rules/index.js:61:35 |
@paustint Perfect. Thanks for doing this. That helps a lot! |
@paustint I just had a closer look at the stack trace. I forgot that we actually read external stylesheets in our update migrations. The error seems to be thrown because we attempt to read a directory. Is it possible that you have a directory ending with |
I don't see any folder with that naming convention, but there is one case where the
@Component({
selector: 'app-edit-record-dfq',
templateUrl: './edit-record-dynamic-form.component.html',
styleUrls: [],
})
export class EditRecordDynamicFormComponent implements OnInit, OnDestroy { |
@devversion - OK - here is some more information. I have another application in the code base with its own
If I run the migration from
|
Thanks @paustint for all the information. This helps a lot. I think there are a few things we could do:
Long-term we should explore (2) as using a glob is obviously not ideal. |
…xtension Previously, we always queried for `.css` and `.scss` files in the whole workspace. We relied on `glob` for this, but did not disable folder matching. Hence, it could happen that in some cases the migration rule tried reading content from a directory (resulting in `EISDIR` error). Additionally, we always queried for files in the actual workspace root. This has downsides and is not correct because it could mean that stylesheets from other projects are accidentally read (in case of a monorepo for example). Fixes angular#18434.
Previously, we always queried for `.css` and `.scss` files in the whole workspace. We relied on `glob` for this, but did not disable folder matching. Hence, it could happen that in some cases the migration rule tried reading content from a directory (resulting in `EISDIR` error). Additionally, we always queried for files in the actual workspace root. This has downsides and is not correct because it could mean that stylesheets from other projects are accidentally read (in case of a monorepo for example). Fixes #18434.
…xtension Previously, we always queried for `.css` and `.scss` files in the whole workspace. We relied on `glob` for this, but did not disable folder matching. Hence, it could happen that in some cases the migration rule tried reading content from a directory (resulting in `EISDIR` error). Additionally, we always queried for files in the actual workspace root. This has downsides and is not correct because it could mean that stylesheets from other projects are accidentally read (in case of a monorepo for example). Fixes angular#18434.
…xtension Previously, we always queried for `.css` and `.scss` files in the whole workspace. We relied on `glob` for this, but did not disable folder matching. Hence, it could happen that in some cases the migration rule tried reading content from a directory (resulting in `EISDIR` error). Additionally, we always queried for files in the actual workspace root. This has downsides and is not correct because it could mean that stylesheets from other projects are accidentally read (in case of a monorepo for example). Fixes angular#18434.
Previously, we always queried for `.css` and `.scss` files in the whole workspace. We relied on `glob` for this, but did not disable folder matching. Hence, it could happen that in some cases the migration rule tried reading content from a directory (resulting in `EISDIR` error). Additionally, we always queried for files in the actual workspace root. This has downsides and is not correct because it could mean that stylesheets from other projects are accidentally read (in case of a monorepo for example). Fixes #18434.
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. |
Reproduction
Steps to reproduce:
ng update @angular/cdk
Because there is not enough information provided by the migration, I am unable to provide a reproduction stackblitz.
Expected Behavior
Successful migration to v9, or at least a meaningful error message that tells me where something might be wrong.
Actual Behavior
What behavior did you actually see?
Any help is much appreciated🙏
Environment
Material: 8.2.1 -> 9.0.0The error seemed similar to this issue angular/angular#31056, but all the examples in that repo shows that additional error information
The text was updated successfully, but these errors were encountered: