foster/denoland-deno
1
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2024-11-22 15:06:54 -05:00
Code Issues Packages 1 Wiki Activity

docs: package.ts -> deps.ts (#1903)

Browse source
This commit is contained in:
Yoshiya Hinosawa 2019-03-09 03:10:14 +09:00 committed by Ryan Dahl
parent 24d6bf6aeb
commit aed3e590ba
1 changed files with 6 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
website/manual.md
View file

@ -490,21 +490,21 @@ network access.
**It seems unwieldy to import URLs everywhere. What if one of the URLs links to
a subtly different version of a library? Isn't it error prone to maintain URLs
everywhere in a large project?** The solution is to import and re-export your
external libraries in a central `package.ts` file (which serves the same purpose
as Node's `package.json` file). For example, let's say you were using the above
external libraries in a central `deps.ts` file (which serves the same purpose as
Node's `package.json` file). For example, let's say you were using the above
testing library across a large project. Rather than importing
`"https://deno.land/std/testing/mod.ts"` everywhere, you could create a
`package.ts` file the exports the third-party code:
`deps.ts` file the exports the third-party code:
```ts
export { test, assertEquals } from "https://deno.land/std/testing/mod.ts";
```
And throughout project one can import from the `package.ts` and avoid having
many references to the same URL:
And throughout project one can import from the `deps.ts` and avoid having many
references to the same URL:
```ts
import { test, assertEquals } from "./package.ts";
import { test, assertEquals } from "./deps.ts";
```
This design circumvents a plethora of complexity spawned by package management