Skip to content

moduleType is not actually a valid config field (unlike moduleTypes) #1630

Description

@dPowNextdoor

Summary

In the website, ReadMe, and other docs, it says moduleType: Override the module type of certain files, ignoring the package.json "type" field. See "Module type overrides" for details.. However moduleType is an internal-only field, not to be used by the tsconfig.json's ts-node field.

Expected Behavior

Any field listed in the website, ReadMe, etc. to be usable.

Actual Behavior

This field (to my knowledge, please correct me if I'm wrong) doesn't do anything. moduleTypes (emphasis on the trailing s) does.

Steps to reproduce the problem

Look through the source code linked above.

Alternatively, don't set type: module in package.json, import some CJS file into your TS file, and then change the tsconfig.json given below from

// no errors
"moduleType": "esm",
"moduleTypes": {
    "**/*.mjs": "esm",
    "**/*.cjs": "cjs"
}

to

// lots of errors
"moduleTypes": {
    "**/*.js": "esm",
    "**/*.mjs": "esm",
    "**/*.cjs": "cjs"
}

and watch ts-node collapse.

Specifications

  • ts-node version: v10.4.0 (latest)
  • node version: v16.13.2
  • TypeScript version: v4.6.0-dev.20220204 (though tested on 4.5.4 and 4.5.5 as well)
  • tsconfig.json, if you're using one:
{
    "compilerOptions": {
        "target": "ESNext",
        "lib": [
            "ESNext",
            "DOM",
            "DOM.Iterable"
        ],
        "module": "ESNext",
        "moduleResolution": "node",
        "strict": true,
        "jsx": "react-jsx",
        "allowJs": true,
        "esModuleInterop": true,
        "allowSyntheticDefaultImports": true,
        "experimentalDecorators": true,
        "emitDecoratorMetadata": true,
        "resolveJsonModule": true,
        "forceConsistentCasingInFileNames": true,
        "newLine": "lf",
        "preserveSymlinks": false,
        "incremental": true,
        "isolatedModules": true,
        "outDir": "dist",
        "declaration": true,
        "declarationDir": "dist/types",
        "baseUrl": ".",
        "paths": {
            "@/*": [ "src/*" ],
            "/*": [ "*" ]
        }
    },
    "include": [
        "./src/**/*"
    ],
    "exclude": [
        "./node_modules",
        "dist"
    ],



    "ts-node": {
        "require": [
            "tsconfig-paths/register"
        ],
        "preferTsExts": true,
        "experimentalReplAwait": true,
        "transpileOnly": true,
        "moduleType": "esm", // Field in question
        "moduleTypes": {
            "**/*.mjs": "esm",
            "**/*.cjs": "cjs"
        },
        "compilerOptions": {
            "module": "nodenext",
            "isolatedModules": false
        },
        "include": [
            "./**/*"
        ]
    }
}
  • Operating system and version: Mac (Big Sur 11.6.1), Linux (Mint Uma)

Related

Maybe this is part of the experimental phase of ts-node, but I had assumed moduleType: "esm" would feign setting type: module in package.json, but clearly it does not. In fact, it doesn't appear to do anything.

Suggested Fix

Either fix (what I assume to be) the typo in the docs, or (preferably) make moduleType do as it currently says it does and override type in package.json.

Activity

  1. cspotcode commented on Feb 7, 2022

    @cspotcode
    Collaborator

    Is this a typo, a missing "s"?

  2. added a commit that references this issue on Feb 7, 2022
    69c75bc
  3. cspotcode commented on Feb 7, 2022

    @cspotcode
    Collaborator

    Fixed by #1633

    The docs on this page are correct: https://typestrong.org/ts-node/docs/module-type-overrides

    See also: #1007 which explains the best way to take advantage of our native ESM support.

  4. added this to the 10.5.0 milestone on Feb 7, 2022
  5. dPowNextdoor commented on Feb 7, 2022

    @dPowNextdoor
    Author

    Thanks @cspotcode! I know this was very minor, but I went down a rabbit hole, confused why moduleType wasn't working. I appreciate the fix (and how quickly it was made)!

  6. cspotcode commented on Feb 7, 2022

    @cspotcode
    Collaborator

    The valid options are also described in the official schema. Some editors can pick this up and assist you.

    https://www.schemastore.org/json/

    image

  7. added a commit that references this issue on Aug 14, 2024
    26c3774
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions