I think this should be a standard problem but I can't find any answers...
I have two typescript projects - LibraryA and WebserverB. They are separate projects and each have their own git repository. They are also private projects - I don't want them to be available in public.
Obviously, I want to use LibraryA in WebserverB. The correct way to do it I think would be through npm, since it manages all other libraries. Luckily npm supports git URLs in dependencies, so I can point it to LibraryA's repository directly.
However that repository doesn't contain the compiled Javascript files, only the TypeScript files. How can I make this work? Or what is the correct approach in this situation?
If you don't want to install your dependency from the sources in a git repository, here are other solutions:
A light solution is to install LibraryA
via a git clone
and to build it. Then, in WebserverB/
, you can do a npm install ../path/to/local/LibraryA
:
- npm install <folder>:
Install the package in the directory as a symlink in the current project. Its dependencies will be installed before it's linked. If <folder> sits inside the root of your project, its dependencies may be hoisted to the toplevel node_modules as they would for other types of dependencies. ( Source: NPM documentation )
You can install a private npm proxy registry on your server, like Verdaccio . Then, you'll be able to publish your package with all compiled files.
You could publish a true package (also with the compiled files) in aprivate repository from a paid account.
The NPM documentation indicates another option:
- npm install <tarball url>
Fetch the tarball url, and then install it. In order to distinguish between this and other options, the argument must start with “http://” or “https://”
Then, publish a package consist to build, compress and upload it as a new release in your private Github repository. After that, it should be possible to access the tarball through an URL using a personal access token?
OK, I'll answer my own question with a summary of the other answers and some extra options.
After some thought I came to a realization. The question is - who and when runs tsc
to compile the LibraryA's Typescript to Javascript? Essentially there are just a few choices:
Let's look at each in detail.
The question then is - where is the published result stored? It has to be somewhere where NPM can access it. As such, there are only a few choices again:
Still, despite the drawbacks, they're all serviceable options.
The main drawback here is that this immediately puts a dependency on typescript on WebserverB. And not just a development-dependency but a full runtime dependency. This may be OK, but it's getting really weird. How do you plan on deploying WebserverB? Will that too run the compilation? I don't think this is the way to go. But it's possible. See HB
's answer for details.
Well, if you plan only on using it in typescript projects, this might be OK. I'm not sure about installing it though. You'll need to modify your tsconfig.json
file to include node_modules/LibraryA
in the compilation. That's weird. And will your IDE be happy about this? All in all, this doesn't feel like a good idea either. It feels like fighting/abusing the system and that rarely ends well.
In the end, I think I'll go with the "commit compiled JS" approach. Because " just wrong " isn't a good argument. And since it's a private project, the extra published sources aren't much of an issue either. In fact, maybe they'll even help to debug.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.