Dynamic Module Loading

[jeremylcarter]

Is there any plan to allow modules to be dynamically added to the build process?

For instance perhaps someone wants to maintain a compatibility module for a particular common node library. They can publish the module package as a "shim" to Nuget. It could then be restored and discovered by SharpTS.

sharpts --shim SharpTS.Shim.Node --compile script.ts

sharpts --shim SharpTS.Shim.Core --shim SomeOverrideShimPackage:fs,path script.ts  # Only use fs,path from SomeOverrideShimPackage

<!-- SharpTS.Shim.Node.csproj -->
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <PackageId>SharpTS.Shim.Node</PackageId>
    <Version>24.0.0</Version>
    <Description>Node.js 24.x API shim for SharpTS</Description>
    <PackageTags>sharpts;nodejs;shim</PackageTags>
  </PropertyGroup>

  <ItemGroup>
    <!-- Reference the shim SDK/interfaces package -->
    <PackageReference Include="SharpTS.Shim.Sdk" Version="1.0.0" />
  </ItemGroup>
</Project>

[nickna]

My apologies for letting this proposal sit so long.

Yes, this is interesting, and you're calling out a much-needed enhancement. My current approach of adding pure IL code for Node libraries is tedious.

There are a couple of ways of getting shim code into SharpTS compiled/interpreted output:

1. Late binding .NET modules: Writing additional modules in separate C#/IL projects and linking to compiled assemblies would incur reflection overhead. It's a minor performance setback I was hoping to avoid. If we're talking about tens or hundreds of Node modules, SharpTS compilations would be faster, while runtime would have a minor overhead when invoking and marshaling code between these modules and the rest of a SharpTS project.

2. TypeScript modules:
Write additional Node libraries in TypeScript. All of the compiled output is baked into a single cohesive .NET assembly, so performance is maintained at the expense of additional compile time.

I'm planning an architecture update to support both methods of shim module support.

[jeremylcarter]

Nick,

Thanks for getting back to me. I think separating the core of SharpTS and the library compatibility is the key feature. That way the core can remain pure, and the libraries can be extended at a faster cadence.

The thing is there are so many little libraries out there that need other little libraries, the dependency graph is huge. I tried to get express running and quickly fell into this hole. Perhaps a combination of approaches is worth it, where late binding is a one off cost, like some kind of scanner (what about a source generator inside a package called SharpTS.SDK. You create all your modules in C# with impl and IL generators for each, then the source generated creates a registry class which can be found at runtime easily.

Then Typescript modules could be an array of additional resolution paths provided. You could then maintain your own Typescript implementations of say left-pad and this moves a fair amount of complexity out of SharpTS's responsibility and back into another repository of pure Typescript mini modules? Could there be a format for these, or just subdirectories as the module names? I think having Typescript pure re-implemented modules might be easier to maintain than impl and IL C# modules.

Happy to discuss and tease this out some more.