Alright, I've decided to provide my own answer by compiling a summary of the existing answers and incorporating some additional options.
Upon reflection, it struck me - who exactly is responsible for running tsc to compile LibraryA's Typescript into Javascript, and when does this process occur? Essentially, there are only a handful of possibilities:
- The developer of LibraryA initiates the compilation and shares the compiled outcome (somewhere);
- LibraryA is released in its source form, with the compilation occurring during package installation on WebserverB;
- LibraryA is distributed in its source form, with the compilation taking place during the build process on WebserverB.
Let's delve into each option in greater depth.
1. Publishing the compiled result
The key question then becomes - where is the published result stored? It must be accessible to NPM. Consequently, the available choices narrow down once again:
- A private or public npm registry if feasible. Drawback: monetary cost associated with this option.
- A tarball hosted on a server accompanied by a URL link. Drawback: necessitates owning a server for hosting purposes and must manage said server.
- A new GIT repository, without being tarballed as npm lacks untarring ability from git repositories. Drawback: results in maintaining two separate repositories for one project.
- Within the same git repository housing LibraryA. Ultimately, this entails committing not just TypeScript source files but also the compiled output. Drawback: against best practices to commit compilation artifacts and exposes sources alongside compiled outcomes which aren't necessary for WebserverB.
- Under the same git repository as LibraryA, yet within a distinct, isolated branch. Drawback: can lead to confusion as to operating multiple repositories with disconnected primary branches.
Despite the drawbacks, all alternatives remain viable.
2. Compiling during installation
The main downside here lies in introducing an immediate dependency on typescript for WebserverB. This isn't solely a development-dependency but rather a full runtime dependence. While this approach might work, it appears unconventional. How do you intend to deploy WebserverB? Will it handle compilation as well? This doesn't seem like the ideal route to take, although it is feasible. For more insights, refer to H.B.'s response.
3. Simultaneous compilation with WebserverB
If your plan centers on using LibraryA solely within TypeScript projects, this method could suffice. However, I'm uncertain about the installation process. Modifying your tsconfig.json file to incorporate node_modules/LibraryA for compilation seems odd. Will your IDE function smoothly with this setup? Overall, this doesn't strike me as a favorable strategy either. It feels like going against the system and may lead to unfavorable outcomes.
In conclusion, I lean towards adopting the "commit compiled JS" strategy. After all, dismissing something as "just wrong" isn't a strong argument. Given that this is a private project, the surplus publication of sources shouldn't pose significant issues. In fact, these additional sources may even aid in debugging processes.