Maszynopis nie kopiuje plików d.ts do kompilacji

Question

Więc może jestem zdezorientowany, ale pomyślałem, że jeśli declaration:truedodam do mojego tsconfig.json, mógłbym go skopiować do moich *.d.tsplików, obok przetransponowanego kodu i jego d.tsplików?

NA PRZYKŁAD:

- src
 - lib
   - types.d.ts
   - foo.ts

Spodziewałbym się, że wynikiem tsc będzie coś takiego:

- build
 - lib
   - types.d.ts
   - foo.js
   - foo.d.ts

Jednak wydaje się, że nie mogę types.d.tszostać skopiowany do katalogu kompilacji.

Czy maszynopis nie zapewnia żadnego mechanizmu kopiowania .d.tsplików? A może po prostu mam gdzieś błędną konfigurację? (W tym momencie wypróbowałem wiele różnych konfiguracji; wydaje się, że nic nie działa)

Answer 1

Masz rację - declaration:trueoznacza, że ​​tylko dla każdego podanego .tspliku tscgeneruje i kopiuje odpowiedni .d.tsplik wyjściowy do buildkatalogu (oprócz .jsi .mapjeśli dotyczy). Więc tscnie skopiuje types.d.tspliku niestandardowego do katalogu wyjściowego.

Zasadniczo .d.tspliki są postrzegane jako nietykalne dane wejściowe dla kompilatora do sprawdzania typu. Nie są używane do generowania danych wyjściowych, co oznacza również, że nie są kopiowane do build. Możesz przeczytać więcejhttps://github.com/Microsoft/TypeScript/issues/5112 o stanowisku opiekunów:

Używane pliki .d.ts są danymi wejściowymi do systemu kompilacji, ale nie są danymi wyjściowymi. Całkowicie rozsądne jest używanie niektórych typów z .d.ts, ale wyjście nie używa tych typów, więc nie byłoby powodu, aby rozprowadzać wejściowe pliki .d.ts z wynikami kompilacji. [...] Wygląda na to, że będziesz chciał wykonać krok po kompilacji w narzędziu do kompilacji, aby skopiować odpowiednie pliki .d.ts, gdziekolwiek ich potrzebujesz.

Pliki .d.ts są uważane za „odniesienia”, kompilator ich nie dotknie, nie przeniesie ani nie utworzy ponownie. Łatwym sposobem myślenia o plikach .d.ts jest to, że są one zgodne z plikami .js. jeśli kopiujesz pliki .js, powinieneś skopiować pasujące pliki .d.ts.

Rozwiązanie nr 1: Skopiuj pliki d.ts za pomocą ręcznego kroku kompilacji

Możliwym rozwiązaniem jest skopiowanie wszystkich potrzebnych .d.tsplików, np. types.d.tsRęcznie na etapie kompilacji. Konkretne narzędzie jest preferowane i zależy od projektu i typu kompilacji, między innymi systemu operacyjnego. To narzędzie powinno zachować strukturę katalogów srcpodczas kopiowania plików build, aby importodniesienia do typów nadal działały. By wymienić tylko kilka:https://serverfault.com/questions/180853/how-to-copy-file-preserving-directory-path-in-linux(Shell) rsync, robocopylub platformy niezależne opakowanie npm jakhttps://www.npmjs.com/package/copyfiles:

"scripts": {
  "copy-dts": "copyfiles -u 1 \"src/**/*.d.ts\" build"
}

Rozwiązanie nr 2: Zmień pliki d.ts na rozszerzenie .ts

Zmień swoje .d.tspliki na .tsrozszerzenie (lub ponownie zintegruj typy z istniejącymi .tsplikami), więc tscdba o emitowanie deklaracji w wyniku. Niewielka wada: nie ma wymuszonej przez kompilator separacji między typami i kodem implementacji ( d.tspliki nie mogą zawierać kodu). Dużą zaletą jest to, że nie potrzebujesz dodatkowego etapu budowy.

Moim zdaniem to drugie jest najłatwiejszym podejściem do wygenerowania publicznego API np. Dla twojego pakietu npm, podczas gdy .d.tsplik mógłby być kandydatem do deklaracji typu używanego wewnętrznie i współdzielonego.

Mam nadzieję, że to pomaga.