-
-
Notifications
You must be signed in to change notification settings - Fork 203
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
Failed to run typescript webpack-config.ts with custom webpack plugin in Angular 13 from compiled mjs format module #1213
Comments
@sergsar Hi, what was the final result here? I'm currently struggling with Angular 13 on this same issue. |
I've decided to get rid of ng build in compiled module used by webpack and exclusively for it I moved on tsc build |
@sergsar Okay, well in my case I can't get rid of the |
You can split your library and move the part that used by webpack config on tsc build and another option to switch webpack config and code from .ts to .mjs in the app and in that case the typings will be lost and that's why I refused it |
Just making sure, you did everything according to the docs, correct? |
@just-jeb Hi, I have certainly tried, based on your docs, and the npm package here: https://www.npmjs.com/package/@angular-builders/custom-webpack/v/13.1.0. I also created a post here: https://stackoverflow.com/questions/tagged/azure-sdk-js |
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
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
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
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
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
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
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
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
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
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
Describe the Bug
Failed to run typescript webpack-config with custom webpack plugin in Angular 13 from compiled mjs module.
An unhandled exception occurred: Unknown file extension ".ts" for /Users/.../webpack-plugin-use-test/webpack.config.ts
[error] TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for /Users/sergej/Projects/local/ng-documentation-test/webpack.config.ts at new NodeError (node:internal/errors:371:5) at Object.file: (node:internal/modules/esm/get_format:72:15) at defaultGetFormat (node:internal/modules/esm/get_format:85:38) at defaultLoad (node:internal/modules/esm/load:13:42) at ESMLoader.load (node:internal/modules/esm/loader:303:26) at ESMLoader.moduleProvider (node:internal/modules/esm/loader:230:58) at new ModuleJob (node:internal/modules/esm/module_job:63:26) at ESMLoader.getModuleJob (node:internal/modules/esm/loader:244:11) at async Promise.all (index 0) at async ESMLoader.import (node:internal/modules/esm/loader:281:24)
Minimal Reproduction
When plugin imported locally from .ts file, there is no error. Every time when .mjs used we have an error: Unknown file extension ".ts"
Could been checked in this project:
https://github.com/sergsar/webpack-plugin-use-test
Expected Behavior
Run typescript webpack-config .ts with custom webpack plugin in Angular 13 from .mjs compliled format module
Environment
The text was updated successfully, but these errors were encountered: