TypeScript ಪ್ರಾಜೆಕ್ಟ್ಗಳು ಬೆಳೆಯುತ್ತವೆ. ಫೈಲ್ಗಳು ಹೆಚ್ಚಾಗುತ್ತವೆ. ಅವಲಂಬನೆಗಳು (dependencies) ಗೊಂದಲಮಯವಾಗುತ್ತವೆ. ಅಂತಿಮವಾಗಿ, ನಿಮ್ಮ ಬಿಲ್ಡ್ ಪ್ರಕ್ರಿಯೆಯು ನಿಮ್ಮ ಲಾಜಿಕ್ನ ಸಂಕೀರ್ಣತೆಯಿಂದಲ್ಲದೆ, ಕೇವಲ ಒಂದು declaration file ಬರೆಯುವ ಮೊದಲು ಕಾಂಪೈಲರ್ ಇಡೀ ವಿಶ್ವವನ್ನೇ ಓದಬೇಕಾದ ಪರಿಸ್ಥಿತಿಯಿಂದಾಗಿ ಅಡಗಿಕೊಳ್ಳುತ್ತದೆ.
TypeScript 6.0 ಇದನ್ನು isolatedDeclarations ಮೂಲಕ ಪರಿಹರಿಸುತ್ತದೆ. ಈ ಫೀಚರ್ .d.ts ಫೈಲ್ಗಳು ಹೇಗೆ ಸೃಷ್ಟಿಯಾಗಬೇಕು ಎಂಬುದನ್ನು ಮರುಚಿಂತನೆ ಮಾಡುತ್ತದೆ. Declaration emission ಅನ್ನು ಪೂರ್ಣ type-checking ಪೈಪ್ಲೈನ್ಗೆ ಕಟ್ಟುಹಾಕುವ ಬದಲು, ಇದು ಪ್ರತಿಯೊಂದು source file ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ (in isolation) ನೋಡಿ ಆ ಫೈಲ್ಗಳನ್ನು ಹೊರಡಿಸಲು (emit) ಕಾಂಪೈಲರ್ಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ, ನಿಮ್ಮ dependency graph ಅನ್ನು ಒಂದೊಂದಾಗಿ ಹುಡುಕುವ ಬದಲು, ಸಾವಿರಾರು ಫೈಲ್ಗಳ ಮೇಲೆ ಸಮಾಂತರವಾಗಿ (parallel) ಕಾರ್ಯನಿರ್ವಹಿಸಬಲ್ಲ ಬಿಲ್ಡ್ ಪ್ರಕ್ರಿಯೆ ಲಭ್ಯವಾಗುತ್ತದೆ.
ನಿಜವಾದ ಅಡಚಣೆ (The Real Bottleneck)
ಪ್ರಸ್ತುತ, declaration ಫೈಲ್ಗಳನ್ನು ತಯಾರಿಸುವುದು ಒಂದು ಸೀರಿಯಲ್ (serial) ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ. ನೀವು --declaration ಅನ್ನು ಎನೇಬಲ್ ಮಾಡಿ ಕಾಂಪೈಲರ್ ಅನ್ನು ರನ್ ಮಾಡಿದಾಗ, ಒಂದು ಮಾಡ್ಯೂಲ್ ಸ್ಪರ್ಶಿಸುವ ಪ್ರತಿಯೊಂದು type ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವವರೆಗೆ TypeScript ಆ ಮಾಡ್ಯೂಲ್ಗಾಗಿ .d.ts ಫೈಲ್ ಅನ್ನು ಹೊರಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಒಂದು ವೇಳೆ utils.ts ಎಂಬುದು types.ts ನಿಂದ type ಗಳನ್ನು ಇಂಪೋರ್ಟ್ ಮಾಡಿದ್ದರೆ, ಮತ್ತು types.ts ಎಂಬುದು api.ts ನಿಂದ ಏನನ್ನಾದರೂ ಪಡೆದಿದ್ದರೆ, utils.ts ಏನನ್ನು ಎಕ್ಸ್ಪೋರ್ಟ್ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುವ ಮೊದಲು ಕಾಂಪೈಲರ್ ಆ ಸರಪಳಿಯನ್ನು (chain) ಪರಿಹರಿಸಲೇಬೇಕು.
ದೊಡ್ಡ monorepo ನಲ್ಲಿ, ಈ ಪ್ರಭಾವವು ಅತ್ಯಂತ ಕಠಿಣವಾಗಿರುತ್ತದೆ. ನಿಮ್ಮ ಇಂಪೋರ್ಟ್ ಗ್ರಾಫ್ನ ಮೂಲದ (root) ಹತ್ತಿರವಿರುವ ಒಂದು ಫೈಲ್ ನೂರಾರು ಡೌನ್ಸ್ಟ್ರೀಮ್ ಫೈಲ್ಗಳ declaration emission ಅನ್ನು ತಡೆಹಿಡಿಯಬಹುದು. ನಿಮ್ಮ CPU ಗೆ ಎಂಟು ಕೋರ್ಗಳಿರಬಹುದು, ಆದರೆ TypeScript ಪ್ರತಿಯೊಂದು ಇಂಟರ್ಫೇಸ್ನ ರೂಪವನ್ನು ಪ್ಯಾಕೇಜ್ ಗಡಿಗಳ ಮೂಲಕ ಕಷ್ಟಪಟ್ಟು ಮರುನಿರ್ಮಿಸುವಾಗ ಏಳು ಕೋರ್ಗಳು ಸುಮ್ಮನೆ ಕುಳಿತಿರುತ್ತವೆ. ಕಾಂಪೈಲರ್ ಅಗತ್ಯ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತಿದೆ ನಿಜ, ಆದರೆ type checking ಮತ್ತು declaration emission ನಡುವಿನ ಈ ಅವಲಂಬನೆಯಿಂದಾಗಿ, ನೀವು ಕೇವಲ ಪಬ್ಲಿಕ್ ಸರ್ಫೇಸ್ type ಗಳನ್ನು ಮಾತ್ರ ಡಿಸ್ಕ್ಗೆ ಬರೆಯಲು ಬಯಸಿದರೂ ಸಹ, ಫೈಲ್-ಕೇಂದ್ರಿತ ವಿಶ್ಲೇಷಣೆಯ ಸಂಪೂರ್ಣ ವೆಚ್ಚವನ್ನು ಭರಿಸಬೇಕಾಗುತ್ತದೆ.
IsolatedDeclarations ನಿಯಮಗಳನ್ನು ಹೇಗೆ ಬದಲಾಯಿಸುತ್ತದೆ
isolatedDeclarations ಆ ಅವಲಂಬನೆಯನ್ನು ಮುರಿಯುತ್ತದೆ. ಈ ಫ್ಲಾಗ್ ಅನ್ನು ಎನೇಬಲ್ ಮಾಡಿದಾಗ, ಕಾಂಪೈಲರ್ ಬೇರೆ ಯಾವುದೇ ಫೈಲ್ ಅನ್ನು ಕೇಳದೆ ಒಂದು source file ಗಾಗಿ .d.ts ಫೈಲ್ ಅನ್ನು ಹೊರಡಿಸಲು ಒಪ್ಪಿಕೊಳ್ಳುತ್ತದೆ. ಇದನ್ನು ಮಾಡಲು ಅದು ಒಂದು ಸರಳ ಒಪ್ಪಂದವನ್ನು (contract) ಬಯಸುತ್ತದೆ: ಪ್ರತಿಯೊಂದು ಎಕ್ಸ್ಪೋರ್ಟ್ ಮಾಡಲಾದ ಸಿಂಬಲ್ (symbol) ಅದು ಘೋಷಣೆಯಾದ ಸ್ಥಳದಲ್ಲೇ ಸ್ಪಷ್ಟವಾದ, ಗೋಚರಿಸುವ type annotation ಅನ್ನು ಹೊಂದಿರಬೇಕು.
ಕಾಂಪೈಲರ್ ಸೋರ್ಸ್ನಲ್ಲಿಯೇ ಬರೆದಿರುವ ಪೂರ್ಣ type ಅನ್ನು ನೋಡಬಲ್ಲದಾದಲ್ಲಿ, ಅದಕ್ಕೆ inference ಮಾಡುವ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ. ಅದು ಇಂಪೋರ್ಟ್ಗಳನ್ನು ಹುಡುಕುವ ಅಗತ್ಯವಿಲ್ಲ. ಇನ್ನೊಂದು ಫೈಲ್ನಲ್ಲಿರುವ User ಎಂಬ ಐಡೆಂಟಿಫೈಯರ್ ಒಂದು interface ಆಗಿದೆಯೇ, type alias ಆಗಿದೆಯೇ ಅಥವಾ class ಆಗಿದೆಯೇ ಎಂದು ತಿಳಿಯುವ ಅಗತ್ಯವೂ ಇಲ್ಲ. ನೀವು ಬರೆದಿದ್ದನ್ನು ಅದು ನೇರವಾಗಿ ಹೊರಡಿಸುತ್ತದೆ.
ಇದರರ್ಥ ಫೈಲ್ A ಮತ್ತು ಫೈಲ್ B ತಮ್ಮ declaration ಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ತಯಾರಿಸಬಹುದು. ಬಿಲ್ಡ್ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಪ್ರತಿಯೊಂದು ಫೈಲ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಥ್ರೆಡ್ಗೆ ನೀಡಬಹುದು. ಪೂರ್ಣ type checker ಇಲ್ಲದ ಕಾರಣ ಈ ಮೊದಲು .d.ts ಜನರೇಷನ್ ಅನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತಿದ್ದ ವೇಗದ ಟ್ರಾನ್ಸ್ಪೈಲರ್ಗಳು (transpilers) ಈಗ declaration ಫೈಲ್ಗಳನ್ನು ಕೂಡ ತಯಾರಿಸಬಹುದು, ಏಕೆಂದರೆ ಈ ಕೆಲಸವು ಕೇವಲ ಸಿಂಟಾಕ್ಟಿಕ್ (syntactic) ಆಗಿರುತ್ತದೆ.
ವಿನಿಮಯ (The Tradeoff): ಅದನ್ನು ಬರೆದು ಇಡಿ
ವೇಗವು ಉಚಿತವಾಗಿ ಬರುವುದಿಲ್ಲ. ನೀವು ಎಕ್ಸ್ಪೋರ್ಟ್ ಮಾಡುವ ಯಾವುದೇ ವಿಷಯಕ್ಕಾಗಿ type inference ಮೇಲೆ ಅವಲಂಬಿತವಾಗುವುದನ್ನು ನಿಲ್ಲಿಸಬೇಕು. ಪ್ರತಿಯೊಂದು ಪಬ್ಲಿಕ್ ಫಂಕ್ಷನ್, ಕ್ಲಾಸ್, ವೇರಿಯಬಲ್ ಮತ್ತು ಕಾನ್ಸ್ಟಂಟ್ಗೆ ಅದರ type ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಬರೆಯಬೇಕಾಗುತ್ತದೆ. ಒಂದು ವೇಳೆ TypeScript ರಿಟರ್ನ್ ಸ್ಟೇಟ್ಮೆಂಟ್ ಅನ್ನು ನೋಡಿ ಅಥವಾ ಜೆನೆರಿಕ್ ಆರ್ಗ್ಯುಮೆಂಟ್ ಅನ್ನು ಪರಿಹರಿಸಿ type ಅನ್ನು ಲೆಕ್ಕಹಾಕಬೇಕಾದಲ್ಲಿ, isolatedDeclarations ಎರ್ರರ್ (error) ತೋರಿಸುತ್ತದೆ.
ಇದು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಹೇಗಿರುತ್ತದೆ ಎಂಬುದು ಇಲ್ಲಿದೆ. ಫ್ಲಾಗ್ ಇಲ್ಲದೆ, ನೀವು ಹೀಗೆ ಬರೆಯಬಹುದು:
export function fetchUser(id: number) {
return fetch(`/users/${id}`).then(r => r.json());
}
TypeScript fetch, ನಂತರ Promise.prototype.then, ನಂತರ r.json() ಅನ್ನು ರಿಟರ್ನ್ ಮಾಡುವ ಅನಾಮಧೇಯ ಫಂಕ್ಷನ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವ ಮೂಲಕ ರಿಟರ್ನ್ type ಅನ್ನು ಇನ್ಫರ್ (infer) ಮಾಡುತ್ತದೆ. .d.ts ಅನ್ನು ಹೊರಡಿಸಲು, ಕಾಂಪೈಲರ್ ಈ ಎಲ್ಲಾ ವಿಶ್ಲೇಷಣೆಗಳನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ.
isolatedDeclarations ಎನೇಬಲ್ ಮಾಡಿದಾಗ, ನೀವು ಎಕ್ಸ್ಪೋರ್ಟ್ ಅನ್ನು ಅ𝗻ೋಟೇಟ್ (annotate) ಮಾಡಲೇಬೇಕು:
interface User {
id: number;
email: string;
}
export function fetchUser(id: number): Promise<User> {
return fetch(`/users/${id}`).then(r => r.json());
}
ಈಗ ಕಾಂಪೈಲರ್ ತಕ್ಷಣವೇ Promise<User> ಅನ್ನು ನೋಡುತ್ತದೆ. ಅದು declaration ಅನ್ನು ಹೊರಡಿಸಿ ಮುಂದಕ್ಕೆ ಸಾಗುತ್ತದೆ.
ಈ ನಿಯಮವು ವ್ಯಾಪಕವಾಗಿ ಅನ್ವಯಿಸುತ್ತದೆ. ಎಕ್ಸ್ಪೋರ್ಟ್ ಮಾಡಲಾದ ಅರೇಗಳಿಗೆ (arrays) ಅವುಗಳ ಎಲಿಮೆಂಟ್ಗಳಿಂದ ಇನ್ಫರ್ ಮಾಡುವುದರ ಬದಲಿಗೆ ಸ್ಪಷ್ಟವಾದ type ಗಳು ಬೇಕು. ಎಕ್ಸ್ಪೋರ್ಟ್ ಮಾಡಲಾದ ಆಬ್ಜೆಕ್ಟ್ಗಳ ರೂಪವು ಬಳಕೆದಾರರಿಗೆ ಮುಖ್ಯವಾಗಿದ್ದರೆ, ಅವುಗಳಿಗೆ ಸ್ಪಷ್ಟವಾದ type annotations ಬೇಕು. ಜೆನೆರಿಕ್ ಫಂಕ್ಷನ್ಗಳಿಗೆ ಅವುಗಳ ರಿಟರ್ನ್ type ಗಳು ಮತ್ತು ಕನ್ಸ್ಟ್ರೈಂಟ್ಗಳು (constraints) ಘೋಷಣಾ ಸ್ಥಳದಲ್ಲೇ ಗೋಚರಿಸಬೇಕು. ಪೂರ್ಣವಾಗಿ ಬರೆಯಲಾದ ಹೆಸರಿಸಿದ type alias ಇಲ್ಲದೆ, ಸಂಕೀರ್ಣವಾದ ಮ್ಯಾಪ್ಡ್ type (mapped type) ನ ಫಲಿತಾಂಶವನ್ನು ನೀವು ಎಕ್ಸ್ಪೋರ್ಟ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಇದರ ಲಾಭವೆಂದರೆ ನಿಮ್ಮ ಪಬ್ಲಿಕ್ API ಸ್ವಯಂ-ದಾಖಲೆ (self-documenting) ಆಗುತ್ತದೆ. ಬಳಕೆದಾರರು ಮತ್ತು ಕಾಂಪೈಲರ್ ಇನ್ನು ಮುಂದೆ ಇಂಪ್ಲಿಮೆಂಟೇಶನ್ ವಿವರಗಳಿಂದ ನಿಮ್ಮ ಉದ್ದೇಶವನ್ನು ರಿವರ್ಸ್-ಎಂಜಿನಿಯರ್ ಮಾಡುವ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ. ಇಲ್ಲಿನ type ಗಳು ಒಂದು ಉದ್ದೇಶಪೂರ್ವಕ ಒಪ್ಪಂದವಾಗಿರುತ್ತವೆ.
ಸಮಯ ಎಲ್ಲಿ ವ್ಯಯವಾಗುತ್ತದೆ
ದೊಡ್ಡ ಕೋಡ್ಬೇಸ್ನಲ್ಲಿ, ಇದರ ಪರಿಣಾಮ ತಕ್ಷಣವೇ ಗೋಚರಿಸುತ್ತದೆ. ಬಿಲ್ಡ್ ಸಮಯವು ನಿಮಿಷಗಟ್ಟಲೆ ಇರಬಹುದು, ಆದರೆ ಈಗ ಅದು ಸೆಕೆಂಡುಗಳಿಗೆ ಇಳಿಯಬಹುದು, ಏಕೆಂದರೆ declaration emission ಎಂಬುದು ಬಿಲ್ಡ್ ಪ್ರಕ್ರಿಯೆಯ ಅತಿ ದೊಡ್ಡ ಅಡಚಣೆಯಾಗಿ ಉಳಿಯುವುದಿಲ್ಲ. ಪ್ರತಿಯೊಂದು ಫೈಲ್ ಸ್ವತಂತ್ರವಾಗಿ ಹೊರಡಿಸಲ್ಪಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಈ ಪ್ರಕ್ರಿಯೆಯು ನಿಮ್ಮ ಇಂಪೋರ್ಟ್ ಗ್ರಾಫ್ನ ಆಳದ ಮೇಲೆ ಅಲ್ಲದೆ, ನಿಮ್ಮ ಬಳಿ ಇರುವ ಕೋರ್ಗಳ ಸಂಖ್ಯೆಯ ಮೇಲೆ ಬೆಳೆಯುತ್ತದೆ.
ಇದು ನೀವು ಬಳಸಬಹುದಾದ ಪರಿಕರಗಳನ್ನೂ (tools) ಬದಲಾಯಿಸುತ್ತದೆ. esbuild ಮತ್ತು swc ನಂತಹ ಟ್ರಾನ್ಸ್ಪೈಲರ್ಗಳು (transpilers) TypeScript ಅನ್ನು JavaScript ಆಗಿ ಪರಿವರ್ತಿಸುವಲ್ಲಿ ಈಗಾಗಲೇ ಅತ್ಯಂತ ವೇಗವಾಗಿವೆ, ಆದರೆ ಅನೇಕ ತಂಡಗಳು ಕೇವಲ .d.ts ಫೈಲ್ಗಳನ್ನು ತಯಾರಿಸಲು ಇನ್ನೂ ಪ್ರತ್ಯೇಕವಾಗಿ tsc ಅನ್ನು ರನ್ ಮಾಡುತ್ತವೆ. isolatedDeclarations ಬಳಕೆಯಿಂದ, ಆ ವೇಗದ ಪರಿಕರಗಳು ಎರಡೂ ಕೆಲಸಗಳನ್ನು ಮಾಡಬಲ್ಲವು. ಡिक्ಲರೇಶನ್ಗಳನ್ನು (declarations) ತಯಾರಿಸಲು ಅವುಗಳಿಗೆ TypeScript ನ ಸಂಪೂರ್ಣ ಟೈಪ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಅನುಕರಿಸುವ ಅಗತ್ಯವಿಲ್ಲ; ಅವು ಕೇವಲ ಸಿಂಟ್ಯಾಕ್ಸ್ ಅನ್ನು ಪಾರ್ಸ್ (parse) ಮಾಡಿ ನೀವು ನೀಡಿದ ಎಕ್ಸ್ಪ್ಲಿಸಿಟ್ (explicit) ಟೈಪ್ಗಳನ್ನು ಕಾಪಿ ಮಾಡಿದರೆ ಸಾಕು. ಇದು ಪರ್ಯಾಯ ಟೂಲ್ಚೈನ್ಗಳೊಂದಿಗೆ (toolchains) ಎಂಡ್-ಟು-ಎಂಡ್ TypeScript ಬಿಲ್ಡ್ಗಳನ್ನು ಹೆಚ್ಚು ಕಾರ್ಯಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ.
ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ (Distributed) ಮತ್ತು ಇನ್ಕ್ರಿಮೆಂಟಲ್ (incremental) ಬಿಲ್ಡ್ಗಳು ಕೂಡ ಸರಳವಾಗುತ್ತವೆ. ಕಂಟಿನ್ಯೂಯಸ್ ಇಂಟಿಗ್ರೇಷನ್ನಲ್ಲಿ (continuous integration), ರಿಮೋಟ್ ಕ್ಯಾಶ್ (remote cache) ಅಥವಾ ಶಾರ್ಡ್ಡ್ ಬಿಲ್ಡ್ (sharded build) ಒಂದು ಪ್ಯಾಕೇಜ್ನ ಪೂರ್ಣ ಟ್ರಾನ್ಸಿಟಿವ್ ಡಿಪೆಂಡೆನ್ಸಿ ಗ್ರಾಫ್ ಅನ್ನು (transitive dependency graph) ಮೊದಲು ಡೌನ್ಲೋಡ್ ಮಾಡದೆ ಅದರ ಡिक्ಲರೇಶನ್ಗಳನ್ನು ಹೊರಡಿಸಬಹುದು. ಮೂಲದಲ್ಲಿ (source) ಟೈಪ್ಗಳು ಎಕ್ಸ್ಪ್ಲಿಸಿಟ್ ಆಗಿದ್ದರೆ, ಬಿಲ್ಡ್ ಶಾರ್ಡ್ಗೆ ಬೇಕಾದ ಎಲ್ಲವೂ ಲಭ್ಯವಿರುತ್ತದೆ.
ಯಾವುದು ಬದಲಾಗುವುದಿಲ್ಲ
ಈ ನಿರ್ಬಂಧವು ಕೇವಲ ಎಕ್ಸ್ಪೋರ್ಟ್ಗಳಿಗೆ (exports) ಮಾತ್ರ ಅನ್ವಯಿಸುತ್ತದೆ. ಒಂದು ಮಾಡ್ಯೂಲ್ನ ಒಳಗೆ, ಎಲ್ಲವೂ ಎಂದಿನಂತೆ ಮುಂದುವರಿಯುತ್ತದೆ. ಲೋಕಲ್ ವೇರಿಯೇಬಲ್ಗಳು (local variables), ಪ್ರೈವೇಟ್ ಕ್ಲಾಸ್ ಮೆಂಬರ್ಗಳು (private class members) ಮತ್ತು ಎಕ್ಸ್ಪೋರ್ಟ್ ಮಾಡದ ಹೆಲ್ಪರ್ ಫಂಕ್ಷನ್ಗಳು (unexported helper functions) ಇನ್ನೂ ಸಂಪೂರ್ಣ ಟೈಪ್ ಇನ್ಫರೆನ್ಸ್ (type inference) ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರಬಹುದು. TypeScript ಯಾವುದೇ ದೂರು ಇಲ್ಲದೆ ಲೂಪ್ ವೇರಿಯೇಬಲ್ ಅಥವಾ ಕ್ಲೋಸರ್ ಪ್ಯಾರಾಮೀಟರ್ನ ಟೈಪ್ ಅನ್ನು ಸುಲಭವಾಗಿ ಇನ್ಫರ್ ಮಾಡುತ್ತದೆ.
export function calculateTotal(items: Item[]): number {
// Local variable: inference is fine
const taxRate = 0.08;
// Private class member inside a local class: inference is fine
class Helper {
private cache = new Map();
}
return items.reduce((sum, item) => sum + item.price * (1 + taxRate), 0);
}
ಕೇವಲ ಎಕ್ಸ್ಪೋರ್ಟ್ ಮಾಡಿದ ಫಂಕ್ಷನ್ ಸಿಗ್ನೇಚರ್ಗೆ (function signature) ಅ𝗻ೋಟೇಶನ್ (annotation) ಅಗತ್ಯವಿರುತ್ತದೆ. ಒಳಗಿನ ಕಾರ್ಯವಿಧಾನವು ಮುಕ್ತವಾಗಿ ಮತ್ತು ಅಭಿವ್ಯಕ್ತವಾಗಿ ಇರುತ್ತದೆ. ಇದು ಬರೆಯುವ ಹೊರೆಯನ್ನು (authoring burden) ಸಹನೀಯವಾಗಿಡುತ್ತದೆ. ನೀವು ಎಲ್ಲೆಡೆ ಸಂಪೂರ್ಣ ಎಕ್ಸ್ಪ್ಲಿಸಿಟ್ ಶೈಲಿಗೆ ಬದಲಾಗುತ್ತಿಲ್ಲ; ನೀವು ಕೇವಲ ಪ್ರತಿ ಮಾಡ್ಯೂಲ್ನ ಗಡಿಯಲ್ಲಿ (boundary) ಒಪ್ಪಂದವನ್ನು (contract) ಔಪಚಾರಿಕಗೊಳಿಸುತ್ತಿದ್ದೀರಿ.
ಇದು ನಿಮ್ಮ ಕೋಡ್ಬೇಸ್ಗೆ (codebase) ಸೂಕ್ತವೇ?
isolatedDeclarations ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವುದು ನೀವು ಸಮಯವನ್ನು ಎಲ್ಲಿ ಕಳೆಯುತ್ತೀರಿ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ನೀವು ಎಕ್ಸ್ಪೋರ್ಟ್ ಬರೆಯುವಾಗ ಕೆಲವು ಹೆಚ್ಚುವರಿ ಕೀಸ್ಟ್ರೋಕ್ಗಳನ್ನು (keystrokes) ಬಳಸುತ್ತೀರಿ, ಮತ್ತು ಬದಲಾಗಿ ಪ್ರತಿ ಬಿಲ್ಡ್ನ ಮೇಲಿನ ಹೊರೆಯಿಂದ ಮುಕ್ತಿ ಪಡೆಯುತ್ತೀರಿ. ಲೈಬ್ರರಿ ಲೇಖಕರಿಗೆ (library authors), ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಸುಲಭವಾದ ಆಯ್ಕೆಯಾಗಿದೆ. ಪಬ್ಲಿಕ್ API ಗಳನ್ನು ಹೇಗಿದ್ದರೂ ಅ𝗻ೋಟೇಟ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಕ್ಲೋಸ್ಡ್ ಮೊನೊರೆಪೊ (closed monorepo) ಒಳಗಿನ ಅಪ್ಲಿಕೇಶನ್ ಡೆವಲಪರ್ಗಳಿಗೆ, ಆರಂಭಿಕ ವೆಚ್ಚವು ಅನಗತ್ಯ ಪ್ರಕ್ರಿಯೆಯಂತೆ ಅನಿಸಬಹುದು. ಆದರೆ ನಿಮ್ಮ ತಂಡವು ಬಿಲ್ಡ್ ಸಮಯವನ್ನು ಕಾಫಿ ಬ್ರೇಕ್ಗಳ ಮೂಲಕ ಅಳೆಯುತ್ತಿದ್ದರೆ, ಈ ವಿನಿಮಯವು ಶೀಘ್ರದಲ್ಲೇ ಆಕರ್ಷಕವಾಗುತ್ತದೆ.
ನೀವು ಇದನ್ನು ಹಂತ ಹಂತವಾಗಿ (incrementally) ಅಳವಡಿಸಿಕೊಳ್ಳಬಹುದು. ಫ್ಲಾಗ್ ಅನ್ನು ಎನೇಬಲ್ ಮಾಡಿ, ಕಂಪೈಲರ್ ಅನ್ನು ರನ್ ಮಾಡಿ ಮತ್ತು ಎಕ್ಸ್ಪೋರ್ಟ್ ಮಾಡಿದ ಸಿಂಬಲ್ಗಳ ಮೇಲೆ ಅದು ತೋರಿಸುವ ದೋಷಗಳನ್ನು (errors) ಸರಿಪಡಿಸಿ. ಯಾವ ಪಬ್ಲಿಕ್-ಫೇಸಿಂಗ್ ಟೈಪ್ಗಳು (public-facing types) ಇಂಪ್ಲಿಸಿಟ್ (implicit) ಆಗಿವೆ ಎಂಬುದನ್ನು ದೋಷ ಸಂದೇಶಗಳು ನಿಮಗೆ ನಿಖರವಾಗಿ ತಿಳಿಸುತ್ತವೆ. ಅವುಗಳನ್ನು ಸರಿಪಡಿಸಿ, ಒಳಗಿನ ವಿಷಯಗಳನ್ನು ಹಾಗೆಯೇ ಬಿಡಿ ಮತ್ತು ನಿಮ್ಮ ಡिक्ಲರೇಶನ್ ಹಂತವು ವೇಗಗೊಳ್ಳುವುದನ್ನು ಗಮನಿಸಿ.
ನೆನಪಿಡಬೇಕಾದ ಒಂದು ವಿಷಯವೆಂದರೆ: ಈ ಫ್ಲಾಗ್ TypeScript ನ ಟೈಪ್ ಚೆಕರ್ ಅನ್ನು ವೇಗವಾಗಿಸುವುದಿಲ್ಲ. ನಿಮ್ಮ ಎಡಿಟರ್ನಲ್ಲಿ ಶೀಘ್ರ ಪ್ರತಿಕ್ರಿಯೆ ಅಥವಾ ವೇಗವಾದ tsc --noEmit ರನ್ಗಳನ್ನು ನೀವು ಬಯಸಿದರೆ, ನಿಮಗೆ ಇನ್ನೂ ಪ್ರಾಜೆಕ್ಟ್ ರೆಫರೆನ್ಸ್ಗಳು (project references), ಕಟ್ಟುನಿಟ್ಟಾದ ಫೈಲ್ ಇನ್ಕ್ಲೂಷನ್ (file inclusion) ಅಥವಾ ಇತರ ಆರ್ಕಿಟೆಕ್ಚರಲ್ ಪರಿಹಾರಗಳು ಬೇಕಾಗುತ್ತವೆ. isolatedDeclarations ನಿರ್ದಿಷ್ಟವಾಗಿ .d.ts ಫೈಲ್ಗಳ ಎಮಿಷನ್ ಅನ್ನು (emission) ಗುರಿಯಾಗಿಸಿಕೊಂಡಿದೆ. ಇದು ಬಿಲ್ಡ್ ಆಪ್ಟಿಮೈಸೇಶನ್ (build optimization), ಟೈಪ್-ಚೆಕಿಂಗ್ ಆಪ್ಟಿಮೈಸೇಶನ್ ಅಲ್ಲ.
ನಿಜವಾದ ಸಾರಾಂಶ
isolatedDeclarations ನಿಮ್ಮ ಪಬ್ಲಿಕ್ ಟೈಪ್ಗಳನ್ನು ಪ್ರಥಮ ದರ್ಜೆಯ ಕಲಾಕೃತಿಗಳಂತೆ (first-class artifacts) ಪರಿಗಣಿಸಲು ಕೇಳುತ್ತದೆ. ಕಂಪೈಲರ್ ಅವುಗಳನ್ನು ಊಹಿಸುವುದನ್ನು (deduce) ನಿಲ್ಲಿಸಿ. ಅವುಗಳನ್ನು ಬರೆದಿಡಿ. ಒಮ್ಮೆ ನೀವು ಹಾಗೆ ಮಾಡಿದರೆ, ಕಂಪೈಲರ್ ಪ್ರತಿ ಬಾರಿಯೂ ಡिक्ಲರೇಶನ್ ಫೈಲ್ ತಯಾರಿಸುವಾಗ ನಿಮ್ಮ ಸಂಪೂರ್ಣ ಡಿಪೆಂಡೆನ್ಸಿ ಗ್ರಾಫ್ ಅನ್ನು ಹುಡುಕುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಇದು ಸಮಾಂತರವಾಗಿ (in parallel) ಎಮಿಟ್ ಮಾಡುತ್ತದೆ, esbuild ಮತ್ತು swc ನಂತಹ ಪರಿಕರಗಳು ಪೂರ್ಣ TypeScript ವರ್ಕ್ಫ್ಲೋಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತವೆ ಮತ್ತು ನಿಮ್ಮ ಮೊನೊರೆಪೊ ಬಿಲ್ಡ್ಗಳು ನಿಧಾನವಾಗುವುದು ನಿಲ್ಲುತ್ತದೆ.
ವೆಚ್ಚವು ಬಿಲ್ಡ್ ಸಮಯದಿಂದ ಬರೆಯುವ ಸಮಯಕ್ಕೆ (authoring time) ಬದಲಾಗುತ್ತದೆ. ಬೆಳೆಯುತ್ತಿರುವ ಹೆಚ್ಚಿನ ತಂಡಗಳಿಗೆ, ಇದು ಮಾಡಬಹುದಾದ ಉತ್ತಮ ವಿನಿಮಯವಾಗಿದೆ.