As I work on building a straightforward ASP.NET Core application utilizing npm and TypeScript, the structure of my project is organized as follows:
/ root
| wwwroot
| js
| AutoGenerated // <-- TS output goes here
| view
| index.html // <-- imports app.js from "AutoGenerated"
| scripts
| app.ts
| node_modules
| ..
| ..
| package.json
| tsconfig.json
| Startup.cs
| Program.cs
The tsconfig
file is configured with
"moduleResolution":"Node"
. For now, I'll skip detailing the rest of the configurations to avoid cluttering the main context.
In my app.ts
, I aim to reference a package downloaded through node. Hence, I included this line:
import { SomeClass } from "@module/downloadedModule";
This import resolves to
"/node_modules/@module/downloadedModule"
, which aligns perfectly with my requirements. The entire project successfully compiles, generating an app.js
file within /wwwroot/js/AutoGenerated/
as expected.
However, the generated JS file still retains references to node_modules:
import { SomeClass } from "@module/downloadedModule";
This situation is problematic since only files under wwwroot
are served by my application.
I stumbled upon a similar query on SO: Cannot import libraries from Node_Modules to ASP.NET CORE APP, where the author proposes extending the static files handler to encompass "node_modules". However, I am hesitant about implementing this in my application.
Here are some potential solutions that cross my mind (although their feasibility remains uncertain):
1.) Mapping essential files from node_modules to e.g., /wwwroot/dependencies
, and adjusting the import path in JS files during TS compilation.
2.) Consolidating my TS files and necessary node_modules dependencies into a unified, self-contained JS file.
3.) Exploring any alternatives that enable me to utilize app.js in my HTML without overwhelming reliance on numerous packages.