How to pre-check or pre-validate form data before submission in React Hook Form?

In React Hook Form, when a form has errors in it, it won’t emit the submit event normally.
However, sometimes it is important to manually handle form validity such as when using validation information from a server.
In that case, it is possible to manually handle the validation via the “mode” property of useForm options by setting it to “onChange”. An example below shows how to do this.
// tsx
import { DOMAttributes } from ‘react’;
import { FormProvider, useForm } from ‘react-hook-form’;
export const MyForm = () => {
  const useFormMethods = useForm<any>({
    mode: ‘onChange’,
  });
  const {
    handleSubmit,
    clearErrors,
  } = useFormMethods;
  const onValidSubmit = useCallback(async (data: any) => {
    // Submit logic
  }, []);
  type OnFormSubmit = DOMAttributes<HTMLFormElement>[‘onSubmit’];
  type OnFormSubmitEvent = Parameters<NonNullable<OnFormSubmit>>[0];
  const onSubmit: OnFormSubmit = useCallback(
    (ev: OnFormSubmitEvent) => {
      // Manually validate values. If OK, proceed:
      clearErrors();
      handleSubmit(onValidSubmit)(ev);
    },
    [clearErrors, handleSubmit, onSubmit],
  );
  return (
    <FormProvider {…useFormMethods}>
      <>
        <form onSubmit={onSubmit}>
    </FormProvider>
  );
}

React Hook Form – Nested useForm in FormProvider? What is recommended? What about for a modal? Elsewhere in DOM via portal?

In React Hook Form, it is a little confusing how to separate multiple input areas in a page.
For example, there may be multiple forms, inputs in completely different areas of the page, modals opening from different triggers, etc.
If you check the Dev Tools, you might see warnings when a form tag is used inside another form tag. It seems using form tags is a bit risky for pages with complex input layouts.

I asked Gemini AI about these issues, and have documented the responses below:


Is it ok to create a react-hook-form using useForm with the FormProvider and then in a nested component create another useForm?


Generally, it’s not recommended to create nested useForm instances within a FormProvider in React Hook Form.

Here’s why:

  • Unnecessary Complexity: A single useForm instance, combined with FormProvider and useFormContext, is usually sufficient to manage complex forms. Creating nested useForm instances can introduce unnecessary complexity and potential issues with form state management.
  • Potential Conflicts: Multiple useForm instances might lead to conflicts in form data and validation. It can be difficult to manage and track the state of different form sections independently.
  • Performance Implications: Creating multiple useForm instances might impact performance, especially for larger forms with many fields.

Recommended Approach:

  1. Use a single useForm instance at the top level of your form component.
  2. Employ FormProvider to provide form context to child components.
  3. Utilize useFormContext within nested components to access form methods and data.

By following this structure, you can effectively manage your form’s state and behavior while maintaining clarity and efficiency.

Example:

JavaScript
import React from 'react';
import { useForm, FormProvider, useFormContext } from 'react-hook-form';

function MyForm() {
  const methods = useForm();

  return (
    <FormProvider {...methods}>
      <form onSubmit={methods.handleSubmit(onSubmit)}>
        {/* Main form fields */}
        <NestedComponent />
        {/* Other form elements */}
      </form>
    </FormProvider>
  );
}

function NestedComponent() {
  const { control } = useFormContext();

  // Access form methods and data using control
  return (
    <div>
      {/* Nested form fields */}
    </div>
  );
}

In this example, useForm is used once at the top level, and useFormContext is employed within NestedComponent to access the shared form context.

Exceptions:

There might be specific use cases where creating nested useForm instances could be considered, but they should be carefully evaluated and approached with caution. For example, if you have highly independent form sections that need to be managed separately, you might explore this option, but it’s generally recommended to find alternative solutions first.

By following these guidelines, you can create well-structured and maintainable forms using React Hook Form.


However, as long as I use two different useForm return value references and do not use useFormContext for the nested useForm data, it should be ok?


Using Separate useForm Instances: A Cautious Approach

Yes, technically, you can use two different useForm instances without useFormContext for nested forms. This approach can work under certain conditions, but it’s generally not recommended due to potential complexities and limitations.

Potential Issues and Considerations:

  • Isolated Form States: Each useForm instance manages its own form data and validation independently. This can make it difficult to synchronize or interact between the two forms, especially if there’s a dependency between them.
  • Complex Data Management: Combining data from multiple forms can become challenging, especially if you need to perform calculations or validations across both forms.
  • Reduced Flexibility: You’ll miss out on the benefits of useFormContext, such as easily accessing form methods and data in nested components.

When it Might Be Acceptable:

  • Completely Independent Forms: If the two forms are truly unrelated and don’t share any data or logic, using separate useForm instances might be reasonable.
  • Specific Use Cases: There might be rare scenarios where this approach is justified, but it’s essential to carefully evaluate the trade-offs.

Recommended Approach:

In most cases, using a single useForm instance with FormProvider and useFormContext is the preferred method for managing nested forms. It offers better control, flexibility, and maintainability.


The problem I have is that the data is related, but is opened from a modal.


Understanding the Challenge: Related Data in a Modal

I understand the challenge. Having related data in a modal context often presents complexities in form management.

Potential Solutions:

  1. Single useForm Instance with Shared State:

    • Centralized Data Management: Create a shared state (e.g., using React Context or a state management library) to store the related data.
    • Form Population: Populate the modal form with data from the shared state.
    • Data Updates: Update the shared state when changes are made in the modal form.
    • Benefits: Enforces data consistency and allows for complex interactions between the main form and the modal.
    • Drawbacks: Increased complexity due to state management.
  2. Separate useForm Instances with Data Transfer:

    • Independent Forms: Create separate useForm instances for the main form and the modal.
    • Data Transfer: Pass the necessary data from the main form to the modal as props.
    • Data Updates: Handle data updates by passing updated data back to the parent component.
    • Benefits: Simpler form management, especially for loosely coupled forms.
    • Drawbacks: Potential for data inconsistencies if not handled carefully.
  3. Custom Form Context:

    • Extended Context: Create a custom form context to share data and methods between the main form and the modal.
    • Data Management: Use the custom context to manage shared data and provide form-related functions.
    • Benefits: More flexibility than built-in useFormContext, allowing for custom logic.
    • Drawbacks: Increased complexity due to custom context implementation.

What does react-hook-form recommend?


React Hook Form Recommendations

React Hook Form generally recommends a single useForm instance for managing form data and validation within a component hierarchy. This approach provides better control, efficiency, and avoids potential issues with state management.

Here are some key recommendations from the React Hook Form documentation:

Core Concepts:

  • useForm: Create a single instance at the top level of your form component.
  • FormProvider: Provide form context to child components using FormProvider.
  • useFormContext: Access form methods and data in nested components using useFormContext.

Best Practices:

  • Default Values: Use the defaultValues prop in useForm to initialize form fields.
  • Validation: Employ built-in validation rules or custom validation functions for robust error handling.
  • Error Handling: Provide clear and informative error messages to users.
  • Accessibility: Ensure forms are accessible to users with disabilities by following accessibility guidelines.
  • TypeScript: Strongly consider using TypeScript for better type safety and code maintainability.

Specific Scenarios:

  • Nested Forms: While generally discouraged, if you must use nested forms, carefully evaluate the trade-offs and consider alternative approaches like shared state or custom context.
  • Complex Forms: For complex forms, explore advanced features like watch, unregister, and formState to manage form state effectively.
  • Performance Optimization: Optimize form performance by using techniques like debouncing, throttling, and lazy loading for large forms.

Even when modals are used?


React Hook Form and Modals: A Single useForm Instance is Preferred

Yes, even when using modals, React Hook Form generally recommends a single useForm instance. This approach provides several benefits:

  • Consistent state management: All form data is managed in a single place, making it easier to track and update values.
  • Efficient performance: A single instance can optimize rendering and re-renders.
  • Simplified code: You avoid the complexities of managing multiple form instances.

How to Handle Modals with a Single useForm Instance:

  1. Create a single useForm instance at the top level of your component hierarchy.
  2. Use FormProvider to provide form context to both your main form and the modal component.
  3. Utilize useFormContext within the modal to access form methods and data.

Example:

JavaScript
import React, { useState } from 'react';
import { useForm, FormProvider, useFormContext } from 'react-hook-form';

function MyForm() {
  const methods = useForm();
  const [isModalOpen, setIsModalOpen] = useState(false);

  const openModal = () => setIsModalOpen(true);
  const closeModal = () => setIsModalOpen(false);

  return   
 (
    <FormProvider {...methods}>
      {/* Main form */}
      <button onClick={openModal}>Open Modal</button>
      {isModalOpen && <Modal onClose={closeModal}>
        <ModalForm />
      </Modal>}
    </FormProvider>
  );
}

function ModalForm() {
  const { register, handleSubmit } = useFormContext();

  // ... modal form content
}

Key Points:

  • Conditional rendering: Use conditional rendering to show or hide the modal based on a state variable.
  • Data flow: Pass necessary data from the main form to the modal as props or through shared state if needed.
  • Form submission: Handle form submission in the parent component to update the main form’s state if required.

Alternative Approaches:

While using a single useForm instance is generally recommended, there might be specific use cases where creating a separate useForm instance for the modal could be considered. However, carefully evaluate the trade-offs and potential complexities before choosing this approach.


So the modal needs to be in the DOM as a child of the form provider? Some libraries force adding to body.


Modal Placement and FormProvider: A Clarification

The placement of a modal within the DOM hierarchy relative to the FormProvider is generally not a critical factor for using React Hook Form effectively.

Key Points:

  • FormProvider’s Scope: The FormProvider creates a context that is accessible to its descendants. Whether the modal is a direct child or positioned elsewhere in the DOM tree doesn’t affect this context’s availability.
  • Modal Libraries: Some modal libraries append elements to the body for styling or accessibility purposes. This is an implementation detail of the library and doesn’t inherently conflict with React Hook Form.

Recommended Approach:

  1. Create a single useForm instance at the top level of your component hierarchy.
  2. Use FormProvider to wrap the main form and any components that need access to form context.
  3. Place your modal component wherever it makes sense in your component structure. This could be a direct child of the FormProvider or a different part of the component tree.
  4. Utilize useFormContext within the modal to access form methods and data.

Example:

JavaScript
import React, { useState } from 'react';
import { useForm, FormProvider, useFormContext } from 'react-hook-form';
import Modal from 'react-modal'; // Or your preferred modal library

function MyForm() {
  const methods = useForm();
  const [isModalOpen, setIsModalOpen] = useState(false);

  // ...

  return (
    <FormProvider {...methods}>
      {/* Main form */}
      <button onClick={() => setIsModalOpen(true)}>Open Modal</button>
      <Modal isOpen={isModalOpen} onRequestClose={() => setIsModalOpen(false)}>
        <ModalForm />
      </Modal>
    </FormProvider>
  );
}

function ModalForm() {
  const { register, handleSubmit } = useFormContext();

  // ... modal form content
}

Additional Considerations:

  • Modal Library Specifics: If your modal library has particular requirements for positioning or context, refer to its documentation for guidance.
  • Performance Optimization: For complex forms or performance-critical applications, consider the impact of modal placement on rendering and re-renders.
  • Accessibility: Ensure that your modal and its content are accessible to users with disabilities.

By following these guidelines, you can effectively use React Hook Form with modals, regardless of their placement in the DOM.


So how can I add the modal to body tag while keeping it inside the FormProvider?


Using React Portals to Append Modal to Body While Keeping it Inside FormProvider

React Portals offer a solution to append a child component to a different part of the DOM while maintaining its relationship with the parent component. This is ideal for modals that often need to be rendered outside the main content area.

Steps:

  1. Import createPortal from React:

    JavaScript
    import { createPortal } from 'react-dom';
    
  2. Create a reference to the body element:

    JavaScript
    const body = document.getElementById('root'); // Or your root element
    
  3. Wrap the modal component in createPortal:

    JavaScript
    <FormProvider {...methods}>
      {/* Main form */}
      {isModalOpen && createPortal(
        <Modal onClose={() => setIsModalOpen(false)}>
          <ModalForm />
        </Modal>,
        body
      )}
    </FormProvider>
    

Complete Example:

JavaScript
import React, { useState } from 'react';
import { useForm, FormProvider, useFormContext } from 'react-hook-form';
import { createPortal } from 'react-dom';

function MyForm() {
  const methods = useForm();
  const [isModalOpen, setIsModalOpen] = useState(false);
  const body = document.getElementById('root'); // Or your root element

  return (
    <FormProvider {...methods}>
      {/* Main form */}
      <button onClick={() => setIsModalOpen(true)}>Open Modal</button>
      {isModalOpen && createPortal(
        <div className="modal">
          <div className="modal-content">
            <ModalForm />
          </div>
        </div>,
        body
      )}
    </FormProvider>
  );
}

function ModalForm() {
  const { register, handleSubmit } = useFormContext();

  // ... modal form content
}

Key Points:

  • The ModalForm component still has access to the form context provided by FormProvider because it’s a descendant.
  • The modal itself is rendered outside the main content area, typically at the end of the body.
  • Ensure appropriate styling for the modal to overlay other content correctly.

By using React Portals, you can effectively combine the benefits of React Hook Form’s context-based approach with the desired placement of your modal.

React Hook Form – How to type the form data with TypeScript types?

This article provides information from Gemini AI regarding how to type React Hook Form form data.
The reasoning for this dialogue is due to there not being clear information about this, and the general loose typing that React Hook Form enforces.
The loose typing I talk about here is how using React Hook Form methods, types are made undefined or null even if the original type did not allow for this.
It seems that it is expected that fields may not be set, so handling of form data should take this into consideration, especially when submitting data.

Please see below for the AI dialogue with more details:


In react-hook-form, when submitting form data and using it for saving via an API, is it recommended to format the data?

It seems like it is easy to have an incorrect format of data due to how react-hook-form works.

Also, what type should I use for the useForm generic parameter to make sure the form data typing is loose enough to require proper checks and formatting?

Also should I trigger form submit with handleSubmit or trigger?


Formatting Form Data for API Submission with React Hook Form

Data Formatting: Absolutely Essential

Yes, it’s highly recommended to format your form data before sending it to the API.

React Hook Form provides a convenient way to manage form state, but it doesn’t inherently guarantee the data structure aligns perfectly with your API’s expectations. Common reasons for formatting include:

  • Data Type Conversion: Converting strings to numbers, dates, or other specific types.
  • Nested Data Structures: Transforming flat form data into nested objects or arrays.
  • API-Specific Formatting: Adhering to required formats like ISO 8601 dates, specific number formats, or custom data structures.
  • Data Validation: Implementing additional validation logic beyond what React Hook Form provides.

By formatting the data, you ensure data integrity and prevent potential API errors.

Generic Type for useForm

To maintain flexibility and accommodate potential data variations, consider using a generic type like any for the useForm parameter:

TypeScript
import { useForm } from 'react-hook-form';

const MyForm = () => {
  const { handleSubmit } = useForm<any>();

  const onSubmit = (data) => {
    // Format data here
    const formattedData = formatData(data);

    // Send formatted data to API
    api.post('/endpoint', formattedData);
  };

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      {/* Your form elements */}
    </form>
  );
};

While any might seem less type-safe, it allows you to handle various data structures without strict type constraints. You can implement custom validation and formatting logic to ensure data correctness.

Triggering Form Submission

Use handleSubmit for form submission.

This is the recommended approach as it provides several benefits:

  • Handles form submission events: Automatically prevents default form behavior.
  • Provides access to form data: Passes the form data to the onSubmit handler.
  • Supports form state management: Manages form state (e.g., isSubmitting, isValid) for better user experience.
JavaScript
const { handleSubmit } = useForm();

const onSubmit = (data) => {
  // ...
};

return (
  <form onSubmit={handleSubmit(onSubmit)}>
    {/* Your form elements */}
  </form>
);

Avoid using trigger for form submission.

While trigger can be used to manually trigger validation, it’s not intended for submitting the form. Using handleSubmit is the standard and recommended way to handle form submissions.

Additional Considerations

  • Leverage TypeScript: If you’re using TypeScript, define custom types for your form data to improve type safety and code maintainability.
  • Create a separate formatting function: Extract data formatting logic into a reusable function for better code organization.
  • Consider a form library: Explore advanced form libraries like formik or yup for additional features and simplified data management.

By following these guidelines and carefully considering your specific requirements, you can effectively handle form data formatting and submission in React Hook Form.

Would you like to see a code example with data formatting and API submission?


any type seems a bit extreme. Is there another type I can use?


Refining the Generic Type in React Hook Form

You’re absolutely right. Using any as a generic type for useForm can be too permissive. Let’s explore more suitable options.

Understanding the Trade-off

The ideal type for useForm balances flexibility with type safety. We want to capture the general shape of the form data without being overly restrictive.

Potential Alternatives

  1. Interface or Type Alias:

    • Define an interface or type alias to outline the expected shape of your form data.
    • This provides basic structure and type checking.
    • Example:
    TypeScript
    interface FormData {
        name: string;
        email: string;
        age: number;
        // ... other properties
    }
    
    const { handleSubmit } = useForm<FormData>();
    
  2. Partial Type:

    • Use Partial<T> to make all properties of an interface optional.
    • This allows for flexibility in case some fields are not present.
    • Example:
    TypeScript
    interface FormData {
        name: string;
        email: string;
        age?: number; // Optional property
        // ... other properties
    }
    
    const { handleSubmit } = useForm<Partial<FormData>>();
    
  3. Generic Interface:

    • Create a generic interface with optional properties for maximum flexibility.
    • Example:
    TypeScript
    interface FormData<T extends Record<string, any>> {
        name: string;
        email: string;
        // ... other common properties
        additionalData?: T;
    }
    
    const { handleSubmit } = useForm<FormData<any>>();
    

Choosing the Right Approach

The best option depends on your specific use case:

  • If you have a well-defined form structure, a specific interface is suitable.
  • If you expect varying form data, a partial type or generic interface offers more flexibility.
  • Consider using TypeScript’s conditional types for more complex scenarios.

Additional Considerations

  • Leverage TypeScript’s Utility Types: Explore utility types like Record, Partial, and Omit to create tailored types.
  • Consider Validation Libraries: Integrate validation libraries like Yup or Zod for robust type checking and data transformation.
  • Balance Type Safety and Flexibility: Strive for a good balance between type safety and accommodating potential data variations.

By carefully considering these factors, you can select the appropriate generic type for your React Hook Form and enhance your application’s type safety.

Would you like to provide more details about your form structure so I can suggest a more specific type?


I’m specifically talking about using types provided by react-hook-form where I can use and pass my expected form data as a parameter to it.


Understanding and Utilizing React Hook Form Types

React Hook Form’s Built-in Types

Unfortunately, React Hook Form doesn’t provide a direct way to specify the entire form data structure as a generic type. The primary focus of its type definitions is on individual field-level interactions and validation.

Recommended Approach: Custom Interface or Type Alias

To achieve the desired level of type safety and structure for your form data, creating a custom interface or type alias is the most effective method. This aligns with the general practice of defining data structures in TypeScript.

Example:

TypeScript
interface MyFormData {
  name: string;
  email: string;
  address: {
    street: string;
    city: string;
    zipCode: string;
  };
  // ... other fields
}

const { handleSubmit } = useForm<MyFormData>();

Leveraging FieldValues for Flexibility

While not directly providing a structure, React Hook Form offers the FieldValues type which can be used as a base for your custom types. This provides some level of type safety and compatibility with the library.

Example:

TypeScript
import { FieldValues } from 'react-hook-form';

interface MyFormData extends FieldValues {
  // Additional properties specific to your form
  customField: string;
}

Key Points

  • Custom Types: Define clear and specific types for your form data.
  • FieldValues: Use FieldValues as a base for custom types if needed.
  • Type Safety: Prioritize type safety to catch potential errors early.
  • Flexibility: Consider using optional properties or generic types for dynamic form structures.

Why do I need a TypeScript declaration file for a JavaScript library even though type checking works in VSCode in own library?

The following is an AI chat conversation regarding the topic stated in the title.
Depending on the quality of the conversation, modifications may have been made. Modifications may or may not be stated in this page.


Why do I need to generate a declaration file for a javascript library in order to get type hinting in VSCode when I use that library in another project? VSCode can already get types of JS file in the same project. So why does this change when importing from an external library?

Here’s a breakdown of why declaration files are required for type hinting in VSCode when using external JavaScript libraries:

1. JavaScript’s Dynamic Nature:

  • JavaScript is dynamically typed, meaning type information isn’t explicitly included in the code itself. This flexibility makes it harder for editors to infer types accurately, especially for external code.

2. VSCode’s Type Hinting Reliance:

  • VSCode heavily relies on type information for features like:
    • IntelliSense (code completion, suggestions)
    • Hover information
    • Parameter and type checking
    • Refactoring tools

3. Separate Project Scope:

  • When a library is in a separate project, VSCode can’t directly analyze its source code to infer types. Declaration files (.d.ts) bridge this gap.

4. Declaration Files:

  • They describe the types of variables, functions, and classes within a library.
  • They’re written in TypeScript, a superset of JavaScript with explicit typing.
  • VSCode can leverage them for type hinting even in JavaScript projects.

5. Type Acquisition Methods:

  • Automatic: VSCode tries to automatically fetch declaration files for popular libraries.
  • Manual: Install declaration files from DefinitelyTyped (a community repository): npm install --save-dev @types/<library-name>
  • Generating: Compile a library’s TypeScript source code or use tools to create .d.ts files from JSDoc comments.

Key Points:

  • Declaration files are essential for type-aware features in VSCode when using external JavaScript libraries.
  • They make your code more readable, maintainable, and less prone to type-related errors.
  • Consider using TypeScript for new projects to enjoy strong typing and type safety from the start.

Should I include code I want typed but not published in tsconfig.json ?

The following is an AI chat conversation regarding the topic stated in the title.
Depending on the quality of the conversation, modifications may have been made. Modifications may or may not be stated in this page.


Should I include code in my tsconfig.json file in “includes” if I want it to be typed, but it is not code for the actual delivered product? For example, if it is build code that I want to be typed.

Whether to include build code in the “includes” list of your tsconfig.json file depends on a few factors:

1. Type Checking and Build Process:

  • If you want type checking and language features for build code during development, include it.
  • If the code is executed as part of the build process (e.g., custom webpack plugins), include it for accurate type checking during build.

2. Performance and Build Size:

  • If type checking build code is unnecessary or impacts performance negatively, exclude it.
  • If including a large amount of build code unnecessarily increases the built JavaScript output, exclude it.

3. Organization and Clarity:

  • If inclusion makes project structure clearer and tooling easier to set up, include it.
  • If exclusion better organizes code for separation of concerns, exclude it.

Best Practices:

  • Separate build code into a dedicated directory for organization and clarity.
  • Use a separate tsconfig.json file specifically for build code, ensuring appropriate configurations without affecting main code.
  • Consider “files” property for explicit file lists instead of “include” for fine-grained control and clarity.

Example tsconfig.json for build code:

JSON
{
  "compilerOptions": {
    // Options tailored for build code
  },
  "include": ["build/**/*.ts"]
}

Recommendations:

  • If build code benefits from type checking or is part of the build process, include it.
  • If performance, build size, or code separation are primary concerns, exclude it.
  • Prioritize clarity, organization, and tooling convenience for effective development.

I want the build code to be included in type checking in VSCode. Would any parent tsconfig.json be detected? Must it be called tsconfig.json?

Here’s how parent tsconfig.json files and type checking in VS Code work:

1. Inheritance:

  • VS Code automatically detects and uses parent tsconfig.json files within the same workspace folder.
  • It merges configurations from parent files, allowing for shared settings and overrides in child files.

2. File Searching:

  • VS Code searches for tsconfig.json files in the following order:
    1. Current workspace folder
    2. Parent workspace folders (recursively)
    3. User-specified path (using the “typescript.tsconfig.autoDetect” setting)

3. File Name:

  • Yes, the file must be named tsconfig.json. VS Code specifically looks for this file name.

Recommendations for VS Code:

  • Position tsconfig.json files strategically: Place them in relevant workspace folders for desired inheritance and configuration sharing.
  • Consider separate files for build code: Isolate build-related configurations for better organization and tailored type checking.
  • Manually specify a parent tsconfig.json: If necessary, use the “typescript.tsconfig.autoDetect” setting to direct VS Code to a specific parent file.

Additional Tips:

  • Use the “extends” property: Explicitly reference a parent tsconfig.json for clarity and maintainability, even within the same workspace folder.
  • Customize workspace settings: Adjust VS Code’s TypeScript settings for specific needs in your project (e.g., enabling or disabling automatic detection).

Example:

  • If you have a top-level tsconfig.json for shared settings and a separate tsconfig.build.json for build code within a nested ‘build’ folder, inheritance and automatic detection will typically work as expected in VS Code.

Research notes regarding converting JSDoc to TypeScript types

A lot of my JS code had been typed with JSDoc comments.
JSDoc comments are very useful for typing JavaScript code, and also have the benefit of allowing inline TypeScript types and importing TypeScript types from ts files. Types can be checked easily in modern editors such as VSCode. For example, the code below, imports from a ts file and types the variable.

/**
* @type {import('tsfile.ts').MyType}
*
const myVariable = 'abc';

It is also possible to declare the type using @typedef to reuse within the file.

/**
* @typedef {import('tsfile.ts').MyType} MyType
*

/*
* @type {MyType}
*/
const myVariable = 'abc';

However, one big issue with JSDoc is that importing it from external libraries seems to not work.
TypeScript types seem to be usable without any processing by just referencing the file such as:

/**
* @typedef {import('my-library'/ts-file-location.ts).MyType} MyType
*/

For JSDoc, generate type declaration files seems to be required.
This is fine, and is expected for JS projects, but it is an extra step that needs to be prepared for all JS projects.

Considering, TypeScript can be imported into JSDoc in the first place, there is really no reason to store type files using JSDoc. The solution is then to isolate types into type only files in ts, and then export each type. This makes it easy to import into JSDoc and into other projects without and processing.

Searching for solutions to convert JSDoc to TypeScript did take my down and long-winding road of issues, that seems to not have been worth the trouble. I have written any significant information in the notes below, but the solution is to just use tsc from TypeScript. See below.

TypeScript tsc

  • Seems to work best. Just need to add exports if necessary and extract from generated file(s).
# Update [SOURCE] below.
# tsc [SOURCE] --declaration --emitDeclarationOnly --allowJs
#
# Notes:
# -- outFile [BUNDLE_DESTINATION] // Works for only some code, so use optionally. https://www.typescriptlang.org/tsconfig/#outFile
# .d.ts file is created in same location with same name before extension.
# To create ts file with exports, SHOULD remove the ".d" part for declaration file, and replace each "type " with "export type ".
# MAY do the same for "interface", but seems like not used (maybe if specifically specified in JSDOC as interface?).
# To prevent replacing wrong code within comments/strings, etc., check that "type" starts at beginning of line.

Notes

ts-migrate

ts-fix

TypeScript codefixes

Other