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

Failed to run typescript webpack-config.ts with custom webpack plugin in Angular 13 from compiled mjs format module #1213

Open
sergsar opened this issue May 17, 2022 · 6 comments · May be fixed by #1659

Comments

@sergsar
Copy link

sergsar commented May 17, 2022

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

  1. Create new Angular 13 empty project
  2. Compile any Webpack Plugin with Angular 13 ng build project
  3. Install compiled module with plugin to initial project
  4. Install @angular-builders/custom-webpack
  5. Add customWebpackConfig configuration with typescript file *.ts
import {CustomWebpackTestPlugin} from "test-webpack-plugin";

export default {
  plugins: [
    new CustomWebpackTestPlugin(),
  ],
};
  1. Run ng serve or ng build

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


Libs
- @angular/core version: 13.3.0
- @angular-devkit/build-angular version: 13.3.5
- @angular-builders/custom-webpack version: 13.1.0

For Tooling issues:
- Node version: 16.13.0
- Platform:  Mac

@robertmazzo
Copy link

@sergsar Hi, what was the final result here? I'm currently struggling with Angular 13 on this same issue.

@sergsar
Copy link
Author

sergsar commented Jan 12, 2023

@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
I left everything the same in the application and I think the Angular command should fix the problem from 14 version of the framework

@robertmazzo
Copy link

@sergsar Okay, well in my case I can't get rid of the ng build process for our application. I'm also trying an empty Angular 14 app to see what happens. Thank you.

@sergsar
Copy link
Author

sergsar commented Jan 12, 2023

@sergsar Okay, well in my case I can't get rid of the ng build process for our application. I'm also trying an empty Angular 14 app to see what happens. Thank you.

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-jeb
Copy link
Owner

Just making sure, you did everything according to the docs, correct?

@robertmazzo
Copy link

@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

@arturovt arturovt linked a pull request Feb 4, 2024 that will close this issue
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
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants