How do I make functions from a specific namespace in a handwritten d.ts file accessible at the module root level?

Question

How do I make functions from a specific namespace in a handwritten d.ts file accessible at the module root level?

Currently, I am working on a repository that consists entirely of JavaScript code but also includes handwritten type declarations (automerge/index.d.ts).

The setup of the codebase includes a Frontend and a Backend, along with a public API that offers some additional convenience functions while re-exporting functions from both the Frontend and Backend.

An example structure is as follows:

declare module `foo` {

  // Functions exclusive to the public API
  function a
  function b
  function c

  // Functions directly exposed from namespace A
  function q
  function r
  function s

  // Functions directly exposed from namespace B
  function x
  function y
  function z

  namespace A {
    function q
    function r
    function s
    function t
  }

  namespace B {
    function v
    function w
    function x
    function y
    function z
  }

}

The provided excerpt from the actual code highlights how we are repetitively declaring re-exported functions, leading to duplication.

declare module 'automerge' {
  ...

  function getObjectById<T>(doc: Doc<T>, objectId: OpId): Doc<T>
  
  namespace Frontend {
    ...

    function getObjectById<T>(doc: Doc<T>, objectId: OpId): Doc<T>
  }

  ...
}

I am seeking guidance on potential strategies to avoid redundant declaration writing in this context. Any insights or solutions would be greatly appreciated!

typescript typescript-declarations typescript-namespace

Answer 1

Answer №1

It seems that achieving what you are looking for may not be possible using namespaces. The use of namespaces is discouraged as they are a legacy feature from the early days of Typescript, according to the official documentation:

[...] modules are recommended over namespaces in modern code.

Additionally:

For new projects, modules are the preferred code organization mechanism.

If you need to provide type definitions, removing the usage of namespaces should be straightforward. One option is to declare exported objects by directly stating their types. For instance, in the case of Frontend, it could be done like this:

const Frontend: {
    // declarations
  };

The above method requires typing the exported function names twice, which can be error-prone, but it should suffice for the number of types you're working with.

Alternatively, another approach is to group related functions together in an auxiliary module, re-export them from there, and import them into the main module:

// Code example

This method is a bit convoluted due to circular imports/exports. Moving all related functions to the "automerge/frontend" module may be an option, but it would require explicit re-exports and potentially change semantics.

To ensure correctness and future-proofing, refactoring the code into modules without circular dependencies is suggested. This may involve creating a common module to consolidate shared types.

If any of the mentioned options interest you, feel free to reach out, and I can help create a pull request for further discussion.

Answer 2

It seems that achieving what you are looking for may not be possible using namespaces. The use of namespaces is discouraged as they are a legacy feature from the early days of Typescript, according to the official documentation:

[...] modules are recommended over namespaces in modern code.

Additionally:

For new projects, modules are the preferred code organization mechanism.

If you need to provide type definitions, removing the usage of namespaces should be straightforward. One option is to declare exported objects by directly stating their types. For instance, in the case of Frontend, it could be done like this:

const Frontend: {
    // declarations
  };

The above method requires typing the exported function names twice, which can be error-prone, but it should suffice for the number of types you're working with.

Alternatively, another approach is to group related functions together in an auxiliary module, re-export them from there, and import them into the main module:

// Code example

This method is a bit convoluted due to circular imports/exports. Moving all related functions to the "automerge/frontend" module may be an option, but it would require explicit re-exports and potentially change semantics.

To ensure correctness and future-proofing, refactoring the code into modules without circular dependencies is suggested. This may involve creating a common module to consolidate shared types.

If any of the mentioned options interest you, feel free to reach out, and I can help create a pull request for further discussion.

Answer 3

Answer №2

Here is a simple illustration, showing how you can prevent duplication in your code:

// utilities.js
const add = (a, b) => a + b;
const multiply = (a, b) => a * b;

Next, create another file:

// calculator.js
import { add } from 'utilities';
export { add };
export * as functions from 'utilities';

Finally, use these functions like this:

// app.js
import { add } from 'calculator';

add(1, 2); // You can only access the "add" function from "calculator".
multiply(3, 4); // This will not work since "multiply" was not explicitly exported.
functions.multiply(3, 4); // However, you can still access it using the "functions" namespace from "calculator".

Answer 4

Here is a simple illustration, showing how you can prevent duplication in your code:

// utilities.js
const add = (a, b) => a + b;
const multiply = (a, b) => a * b;

Next, create another file:

// calculator.js
import { add } from 'utilities';
export { add };
export * as functions from 'utilities';

Finally, use these functions like this:

// app.js
import { add } from 'calculator';

add(1, 2); // You can only access the "add" function from "calculator".
multiply(3, 4); // This will not work since "multiply" was not explicitly exported.
functions.multiply(3, 4); // However, you can still access it using the "functions" namespace from "calculator".

Answer 5

Answer №3

To solve this issue, one approach is to create a type alias for an arrow function and use it in multiple places. For example:

declare module "automerge" {
    type GetObjectById = <T>(doc: Doc<T>, objectId: OpId) => Doc<T>
    
    const getObjectById: GetObjectById

    namespace Frontend {
        const getObjectById: GetObjectById
    }
}

Unfortunately, the same cannot be done directly with traditional function declarations (see here).

Arrow functions and regular function declarations have differences, especially in terms of the scoping of this inside the function. Arrow functions, for instance, do not support a this parameter like regular functions do:

// not allowed
const fn = (this: SomeContext) => void
// allowed
function fn(this: SomeConext): void

If your code does not rely on these differing features, or if you can switch to using arrow functions in your JavaScript code for safety, then this solution should suffice.

Answer 6

To solve this issue, one approach is to create a type alias for an arrow function and use it in multiple places. For example:

declare module "automerge" {
    type GetObjectById = <T>(doc: Doc<T>, objectId: OpId) => Doc<T>
    
    const getObjectById: GetObjectById

    namespace Frontend {
        const getObjectById: GetObjectById
    }
}

Unfortunately, the same cannot be done directly with traditional function declarations (see here).

Arrow functions and regular function declarations have differences, especially in terms of the scoping of this inside the function. Arrow functions, for instance, do not support a this parameter like regular functions do:

// not allowed
const fn = (this: SomeContext) => void
// allowed
function fn(this: SomeConext): void

If your code does not rely on these differing features, or if you can switch to using arrow functions in your JavaScript code for safety, then this solution should suffice.

Answer 7

Answer №4

If you're looking for a solution, consider implementing something similar to this:

declare module 'automerge' {
  
  namespace Frontend {
    function getObjectById<T>(doc: T, objectId: any): T;
  }
  
  const getObjectById: typeof Frontend.getObjectById;

}

Give it a try on the playground

Advantages:

Streamlines code duplication by utilizing existing function typings.

Drawbacks:

Doesn't completely remove the necessity of declaring const/function with the same name twice.

Answer 8

If you're looking for a solution, consider implementing something similar to this:

declare module 'automerge' {
  
  namespace Frontend {
    function getObjectById<T>(doc: T, objectId: any): T;
  }
  
  const getObjectById: typeof Frontend.getObjectById;

}

Give it a try on the playground

Advantages:

Streamlines code duplication by utilizing existing function typings.

Drawbacks:

Doesn't completely remove the necessity of declaring const/function with the same name twice.

How do I make functions from a specific namespace in a handwritten d.ts file accessible at the module root level?

Answer №1

Answer №2

Answer №3

Answer №4

Similar questions

Issues with Angular2 causing function to not run as expected

What is the most appropriate form to use, and what factors should be considered in determining

Angular 8 does not show the default option in the select tag

Avoiding repetitive logic in both parent and child components in Angular 8

Needing to utilize the provide() function individually for every service in RC4

Issue encountered while trying to determine the Angular version due to errors in the development packages

Exploring the potential of the forkJoin operator in Angular 4's Observable

Incorporate a typescript library into your Angular application

Creating a TypeScript function that automatically infers the type of the returned function using generics

How to nullify the valueChanges pipe in Angular RxJS until the observable is resolved

"Setting Up a Service in Angular: A Step-by-Step Guide

What is causing the issue with TypeScript's React.createRef() and its compatibility with the material-ui Button element?

Why does mapping only give me the last item when I try to map onto an object?

Guide to simulating a function using .then within a hook

Tips on customizing the appearance of the dropdown calendar for the ngx-daterangepicker-material package

Encountering an issue while trying to import the validator module in NextJS 13

Aliases for NPM packages and TypeScript declaration files

Is there a way to include values in the body of an HTTP GET request using Angular?

Data not being retrieved by HTTP GET request

Only JSON objects with a boolean value of true will be returned