Czy ma sens używanie argumentu „eksport” w pliku „d.ts”?
Próbuję utworzyć plik dla typów, które są używane globalnie w mojej aplikacji.
reduxState.d.ts
declare namespace MyProject {
  type Type1 = someType;
  interface SomeInterface {
    someProperty: someType
  }
}
 
    Dzięki powyższemu kodowi mogę już zobaczyć moje namespacei jego członków dostępne w moich plikach projektu.
Jaka jest więc różnica między powyższym kodem a następującym kodem używanym exportprzez namespaceczłonków?
declare namespace MyProject {
  export type Type1 = someType;
  export interface SomeInterface {
    someProperty: someType
  }
}
 
    Oboje wydają się działać dobrze. Jaka jest różnica?
Od: https://www.typescriptlang.org/docs/handbook/namespaces.html#namespacing
Ponieważ chcemy, aby interfejsy i klasy tutaj były widoczne poza przestrzenią nazw, poprzedzamy je eksportem.
W tym fragmencie DOC wydaje się, że odnoszą się do elementu namespacezadeklarowanego w pliku, tsa nie do d.tspliku. Czy dlatego potrzebujesz exportw takim przypadku?
Czy w ogóle ma sens używanie exportw d.tspliku?
Odpowiedzi
*.d.tspliki są przeznaczone do definicji, są całkowicie ignorowane w czasie wykonywania. Jeśli piszesz kod JS, ponieważ masz bibliotekę lub coś w tym stylu, zdecydowanie zalecam użycie słowa kluczowego export, ponieważ ułatwia to innym użytkownikom zobaczenie, czego będą mogli użyć z twojego kodu (coś, czego nie eksport, oczywiście nie można ich importować gdzie indziej).
Teraz twój przypadek użycia: wszystko, co jest wyeksportowane z przestrzeni nazw, może być używane poza nim niezależnie. To znaczy, że możesz zrobić coś takiego
const obj: MyProject.SomeInterface = { someProperty: 20 };
 
     Ponieważ używasz *.d.tsplików, a nie *.tsplików, nie zrobi to dla ciebie żadnej różnicy, o ile eksportujesz tylko interfejsy, ponieważ i tak zostaną one pominięte w czasie kompilacji.
Ostatnia uwaga: *.d.tsdzięki plikom możesz zobaczyć swoje rzeczy w całym projekcie, ale jeśli planujesz importować funkcje lub podobne, musisz je najpierw zaimportować.