Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Epic: No-.NET-required distribution — self-contained managed SKU + Native AOT SKU

Aperta
  • Qualcosa non va?
#1,324 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
csharp, typescript
Ambito
ci-cd, release

Direzione di ricerca

Inizia da docs/plans/native-aot.md e dai sei job di release nativi esistenti su main. Crea il tag della prima release di SharpTS, conferma che tutti e sei i job nativi vengano eseguiti e verifica che i dodici archivi managed/native siano allegati per i sei RIDs elencati.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement epic

Goal

Offer SharpTS on machines with no .NET installed as two deliberately different SKUs:

  • Managed SKU — self-contained single-file per RID and the default for the full feature set, especially .NET/third-party interop.
  • Native SKU — Native AOT for the frozen straight-TypeScript surface, with lower startup overhead and explicit diagnostics for unsupported features.

The verified design and measurements live in docs/plans/native-aot.md. PE-Packer's completed tracker is nickna/PE-Packer#20; its older AOT markdown is historical context.

Current status

All SharpTS source and PE-Packer package-integration work is merged and green on main. SharpTS pins NickNa.PEPacker 1.0.6, and PR #1331 plus its post-merge run passed the exact analyzer ratchet, both managed suites, and the Linux Native AOT compile/bundle smoke. The only remaining release checkpoint is the first SharpTS tag and its six-platform asset validation.

Completed

  • Track 0 — #1325: exact AOT/trim/single-file analyzer ratchet (2,585 warnings), six-RID managed self-contained release assets, and release-binary smokes.
  • Phase 1 — #1327: compile-time NodeRegistry dispatch, reflection-free JSON paths, native fail-fast diagnostics, and -SharpTSExe example-harness support.
  • Native compile gate — #1328: both ILCompiler pipelines run from Native AOT; CA blobs, generic emit fallbacks, required trim/metadata settings, embedded reference index, and PE-Packer bundling are exercised in CI.
  • Managed runtime handoff — #1329: the native compiler embeds an AnyCPU managed SharpTS runtime, extracts it atomically for compiled soft dependencies, runs eval() under CoreCLR, and rejects compiled child_process.fork before writing output.
  • Distribution source — #1330: tagged releases build and execute win-x64/arm64, linux-x64/arm64, and osx-x64/arm64 Native AOT assets on matching-architecture runners. Windows/Linux require SDK-free PE-Packer executable creation; macOS verifies the named built-in-bundler refusal.
  • PE-Packer 1.0.6: reference policy/index APIs, six embedded Windows/Linux apphosts, and the consumer-controlled SDK-bundler feature switch are released.
  • Published-package integration — #1331: SharpTS pins 1.0.6 and its permanent native smoke creates and executes a PE-Packer bundle with DOTNET_ROOT empty.

Release checkpoint

  • All required SharpTS and PE-Packer source changes are merged.
  • NickNa.PEPacker 1.0.6 is published with embedded apphosts and the SDK-bundler feature switch.
  • SharpTS consumes 1.0.6; its PR and post-merge main CI are green.
  • Tag the first SharpTS release, confirm all six native jobs run, and verify all twelve managed/native archives are attached.

The SharpTS tag is now unblocked. Treat its six native release jobs and twelve attached managed/native archives as the cross-platform acceptance event.

Decisions settled

  • The managed SKU remains the full-feature default; Native AOT is the straight-TypeScript SKU.
  • SharpTS.Sdk stays managed and RID-neutral. It already runs under dotnet build and forwards the project ReferencePath through -r; substituting the native compiler would lose its interop contract while multiplying package payloads without removing a .NET prerequisite.
  • Native distribution is the standalone sharpts-native-<version>-<rid> release asset. A separate opt-in native MSBuild SDK is future work only if measurements justify it.
  • Built-in --target exe remains Windows/Linux-only until PE-Packer implements Mach-O adjustment and ad-hoc signing.
  • Native losses remain explicit: interpreter third-party DLL loading, compile-time third-party refs, --verify, --gen-decl, compiled child_process.fork, and unsupported runtime-generated generic/interoperability shapes route users to the managed SKU.

Measured facts worth preserving

  • Native interpretation moved from roughly 9x slower than JIT to faster than JIT after source-generated dispatch (local dispatch-heavy median about 1,370 ms native vs 1,648 ms JIT).
  • Native compile, multi-module output, embedded managed-runtime extraction, and PE-Packer bundle execution pass on win-arm64 locally and linux-x64 in CI.
  • PE-Packer's feature switch removed every SdkBundler implementation symbol from the win-arm64 ILC map and saved 134,144 bytes (2.91%) in its current smoke image.
  • With PE-Packer 1.0.6, local win-arm64 SharpTS created and ran a 355,651-byte target executable with DOTNET_ROOT empty; the native SharpTS image contained zero InvokeSdkBundler occurrences.

Non-blocking follow-up after the first release

  • Define and test any BCL interop surface we want to promise in the native SKU; the known dynamic-event edge remains outside the straight-TypeScript release contract.
  • File/investigate the pre-existing MetadataLoadContext-types-into-TypeBuilder limitation upstream if native compile-time third-party references become a goal.
  • The optional Packaging/ dependency reduction and an opt-in native SDK package are separate optimizations, not AOT release blockers.
Lingua principale
C#
Stelle
156
Fork
4
Merge medio
2h 30m
PR unite (30g)
179

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di nickna/SharpTS

Tutte le issue di nickna/SharpTS

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.