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

ENOENT: no such file or directory, realpath #1730

Open
muuvmuuv opened this issue Mar 28, 2024 · 7 comments · May be fixed by #1659
Open

ENOENT: no such file or directory, realpath #1730

muuvmuuv opened this issue Mar 28, 2024 · 7 comments · May be fixed by #1659

Comments

@muuvmuuv
Copy link

Describe the Bug

Angular with latest TypeScript semver range supports direct import.

An unhandled exception occurred: ENOENT: no such file or directory, realpath '/Users/marvin/Developer/M8FINDER/M8FINDER/.angular/vite-root/app'
See "/private/var/folders/nb/bwd6_n3d3y583d365z6mcb200000gn/T/ng-Q5hK1L/angular-errors.log" for further details.

https://github.com/just-jeb/angular-builders/blob/master/packages/common/src/load-module.ts#L84-L87

Must be changed to:

return import(modulePath).then((module) => module.default);

Minimal Reproduction

Note: Our policy is that issues reported without a reproduction will be closed immediately and then reopened once a reproduction has been provided. Please respect the developers of this project by doing this. We give of our personal time to work on this project and would rather be spending our time fixing or enhancing the library than chasing down badly described or unreproducible issues.
Please delete this note once you have read it.

Expected Behavior

A clear and concise description of what you expected to happen.

Screenshots

If applicable, add screenshots to help explain your problem.

Environment


Libs
- @angular/core version: 17.3.2
- @angular-devkit/build-angular version: 17.3.2
- @angular-builders/custom-esbuild version: 17.1.1

For Tooling issues:
- Bun version: 1.0.35
- Platform:  Mac

Others:

Additional Context

Add any other context about the problem here.

@arturovt arturovt linked a pull request Apr 4, 2024 that will close this issue
arturovt added a commit that referenced this issue Apr 4, 2024
This commit updates the implementation for resolving `.ts` files.
Instead of registering the `ts-node` project only once, we now refrain from
doing so since there might be multiple projects with different configurations.
The current approach involves dynamically switching the implementation for
registering and unregistering the project after the `.ts` file has been transpiled
and resolved. This change addresses an issue where warnings were encountered when
`ts-node` attempted to register with different configurations. The number of configurations
is no longer a concern, as each time we need to read a `.ts` file, a new TS project is
registered. This adjustment does not impact performance or other attributes because `ts-node`
allows native project disabling. Part of the implementation has been adapted from what Nrwl Nx
already has; we can find their implementation here:
https://github.com/nrwl/nx/blob/master/packages/nx/src/plugins/js/utils/register.ts
It's worth noting that their implementation is somewhat versatile, as it also supports SWC.

Closes: #1197
Closes: #1213
Closes: #1730
arturovt added a commit that referenced this issue Apr 4, 2024
This commit updates the implementation for resolving `.ts` files.
Instead of registering the `ts-node` project only once, we now refrain from
doing so since there might be multiple projects with different configurations.
The current approach involves dynamically switching the implementation for
registering and unregistering the project after the `.ts` file has been transpiled
and resolved. This change addresses an issue where warnings were encountered when
`ts-node` attempted to register with different configurations. The number of configurations
is no longer a concern, as each time we need to read a `.ts` file, a new TS project is
registered. This adjustment does not impact performance or other attributes because `ts-node`
allows native project disabling. Part of the implementation has been adapted from what Nrwl Nx
already has; we can find their implementation here:
https://github.com/nrwl/nx/blob/master/packages/nx/src/plugins/js/utils/register.ts
It's worth noting that their implementation is somewhat versatile, as it also supports SWC.

Closes: #1197
Closes: #1213
Closes: #1730
@just-jeb
Copy link
Owner

just-jeb commented Apr 4, 2024

Do you know what's the minimal requirement for Angular/TS here @muuvmuuv ? Trying to figure out if we can release such a change in a minor version without breaking everyone.

@muuvmuuv
Copy link
Author

muuvmuuv commented Apr 4, 2024

I already tried to but its hard to say. We would need tests for that to check against lower semver ranges. But since it no longer works on my end between these and the previous version I would say this is the range.

@muuvmuuv
Copy link
Author

Would it make sense to grab that here after v18 release since TS version is now high enough?

@just-jeb
Copy link
Owner

Absolutely, I'd say if anything it must be part of v18 release (since as part of breaking changes we can require minimal TS version).
Do you think you'd have time to make a PR with this change into v18 PR?

@muuvmuuv
Copy link
Author

Yeah ofc. But I don't think I can write tests for that, Jest is kinda picky with mixed import syntax so it wont be ez.. maybe a custom test suite in shell-script with tsc?

@muuvmuuv
Copy link
Author

Just something I discovered developing in angular-builders is that "@lerna-lite/run" is missing in order to do something like: yarn lerna run --scope @angular-builders/common test OR how do you execute scripts inside a package?

@just-jeb
Copy link
Owner

maybe a custom test suite in shell-script with tsc?
Yeah, e2e test are probably the way to go. We already have custom shell scripts for e2e tests, for example this one for custom-webpack builder or this one for the Jest builder.

I think that the existing e2e tests for builders will implicitly cover the change (coz they depend on @angular-builders/common and use loadModule) but feel free to add more and/or add a proprietary ci shell script for common.

how do you execute scripts inside a package

We use yarn workspaces foreach for multiple packages or yarn workspace for a single package (like here). In most cases this should be enough.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants