Build Warning with Angular Universal - Register ts-node again #1197
Comments
|
This is not reproducible locally (at least I ain't able to). |
|
Did you update all builders to use webpack? Did you run J |
|
Yes. Note that you opened an issue w/o a reproducible example but it was required:
|
|
Fair enough. I will create a sample repository today after work. Thanks, J |
|
Here is a repository that shows the current error messages by running https://github.com/jdgamble555/angular-error-test (Because you guys have not yet updated to Angular 15, this uses the last version of Angular 14). Thanks, J |
|
I am getting the same error. Is there any information why it occurs? |
|
arturovt
added a commit
that referenced
this issue
Feb 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
arturovt
added a commit
that referenced
this issue
Feb 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
arturovt
added a commit
that referenced
this issue
Feb 17, 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
arturovt
added a commit
that referenced
this issue
Mar 10, 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
arturovt
added a commit
that referenced
this issue
Apr 3, 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
arturovt
added a commit
that referenced
this issue
Apr 3, 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
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
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
arturovt
added a commit
that referenced
this issue
Sep 19, 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am getting this warning with Angular Universal:
This started once I switched over to Webpack. Here is my angular.json.
I believe it to be a bug in the compilation...
J
The text was updated successfully, but these errors were encountered: