Skip to content
On this page


Modules are reusable code bundles distributed via URLs. Netzo makes it easy to author and deploy Modules on the click of a button. Modules can be private or public, in which case they can be imported by third-party scripts (without authentication).

Authoring modules directly within Netzo provides several benefits.

  • Skip the DevOps: all modules are automatically hosted by Netzo on the web, no need for package management or CLI tools like npm.
  • Flexibility of local: add documentation in markdown, diagrams as images, and even custom HTML pages along your code. Netzo will host and serve these for you automatically.
  • Link to Git repositories: a module can be linked to a git Repository (e.g. via GitHub), for advanced version control. Netzo will keep changes in sync automatically.
  • Visibility: keep all your modules together for a better overview and availability when developers need it.
  • Flexiblity: modules can be imported from any location on the web, like GitHub, a personal webserver, or a CDN like Skypack,, jsDelivr or
  • Stability: all modules published in Netzo are versioned so any breaking changes never affect scripts.

Module Syntax

Deno by default standardizes the way modules are imported in both JavaScript and TypeScript using the ECMAScript 6 import/export standard.

It adopts browser-like module resolution, meaning that file names must be specified in full. You may not omit the file extension and there is no special handling of index.js.

Deno allows importing modules either locally or remotely

  • import allows you to include and use modules held elsewhere, on your local file system or remotely.
  • export allows you to specify which parts of your module are accessible to users who import your module.

Exporting Modules

All exports in a file (code exposed using export keyword) will be made available for others to import (using import keyword) under a URL with a common structure.<module_name>@<tag_name>/<file_path>

For example, the main entry point for the Netzo SDK can be found under

Or more specifically by providing the version's tag_name of the module[email protected]/src/mod.ts


The URL without the tag_name will successfully resolve to the latest published version of the module. However, it is adviced that you always import from a specific version to programms which depend on the module form breaking when a new version (with breaking changes) is published.

Importing Modules

There are two types of exports, and thus, two types of imports.

  1. Default: allow exporting and importing an entire module
  2. Named: allow exporting and importing single components within a module

Similarly, there are two ways of importing these default and/or named exports.

  1. Static imports: allow exporting and importing modules at load time
  2. Dynamic imports: allow exporting and importing modules at run time

Static Imports

The standard import syntax is static and will always result in all code in the imported module being evaluated at load time.

// for default exports (with an alias)
import someModule from '<module_name>@<tag_name>/<file_path>'

// for named exports (any optionally with an alias)
import { someFunction, someOtherFunction as myFunction } from '<module_name>@<tag_name>/<file_path>'

// importing all named exports into a single object (with an alias)
import * as namedExports from '<module_name>@<tag_name>/<file_path>'

Dynamic Imports

In situations where you wish to load a module conditionally or on demand, you can use a dynamic import instead.

// for default exports (with an alias, required since default is reserved keyword)
const { default: someModule } = await import('<module_name>@<tag_name>/<file_path>')

// for named exports (any optionally with an alias)
const { someFunction, someOtherFunction: myFunction } = await import('<module_name>@<tag_name>/<file_path>')

The above makes use of ES destructuring assignment syntax, used to unpack values from arrays, or properties from objects into distinct variables, in this case from the dynamically imported module.

Import Maps (coming soon)

Import maps allows control over what URLs get fetched by import statements and import() expressions. They can be thought of as shortcuts to map short and memorable aliases to (longer) import URLs. Deno will resolve imports based on an import_map.json file.

  "imports": {
    "netzo/": ""

The location of the import_map.json file can be set via the importMap field of deno.json. By default, this is the root of the Deno module.

Publishing Modules

Netzo will automatically publish all your modules, no need to do so manually via npm publish for example. Modules are composed of regular static files hosted by Netzo and served with an appropriate Content-Type header.

The following table gives an overview of the currently supported file types for serving files:


Key: ✅ - supported, ⌛ - work in progress, ❔ - in consideration, N/A - not applicable

Not on the list?

Do not hesitate to contact us by email at [email protected] or by filling out this form.

File extensions are mandatory and used to serve file contents with the appropriate Content-Type header.

A complete absolute or relative file path (including extension) is required when pointing to module files.

Deno encourages using mod.(ts|js) as the module entry point, as there is no special handling for index.(ts|js) paths. This is to avoid the common practice of importing files by ommiting the index.(ts|js) filename, common in for example Node.js, which goes against web URL semantics.

Publishing Official Deno Modules

Modules can also be published to the Deno ecosystem via the official hosting service. It caches releases of open source modules and serves them at one easy to remember domain. Navigate to their official docs to learn more.

For simpler modules it is recommended to have a single mod.(ts|js) file at the module entry point. When modularizing a larger module, it adviced to keep the mod.(ts|js) entry point as lean as possible (using only import/export statements), keeping business logic in other files.


Netzo uses SemVer syntax to version module deployments. In this way, any previous deployment made in Netzo is hosted forever under the same URL, preventing programs which depend on it from breaking when the module is updated.

We recommend starting your package version at 1.0.0 and incrementing as follows:

Code statusStageRuleExample version
First releaseNew productStart with
Backward compatible bug fixesPatch releaseIncrement the third digit1.0.1
Backward compatible new featuresMinor releaseIncrement the middle digit and reset last digit to zero1.1.0
Changes that break backward compatibilityMajor releaseIncrement the first digit and reset middle and last digits to zero2.0.0


In summary, Modules make it easy to...

  • share code across teams
  • collaborate to avoid rework
  • enforce code standards
  • continuously integrate changes
  • use modern, fast, web-based development tools
Modules has loaded