Skip to content

Provide more information when there is a SyntaxError #56830

Closed
Closed
Provide more information when there is a SyntaxError#56830
Labels
strip-typesIssues and PRs related to TypeScript type stripping.

Description

@Ethan-Arrowood
Ethan-Arrowood
opened on Jan 14, 2025

I'm working on migrating a large JS/TS repo to using Node.js v23 type-stripping. I've already applied some codemods to transform requires & imports, as well as remove TS specific syntax. I'm now running into some syntax errors regarding missing exports which I think were silently being ignored previously. The error does not say what file it is coming from and that is proving difficult to track down. Can amaro print that info? Thank you!

For example:

> node bin/harperdb.js                                                                                                                                                          
(node:25707) ExperimentalWarning: Type Stripping is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
(node:25707) [MODULE_TYPELESS_PACKAGE_JSON] Warning: Module type of file:///Users/ethan/dev/harperdb/harperdb/resources/databases.ts is not specified and it doesn't parse as CommonJS.
Reparsing as ES module because module syntax was detected. This incurs a performance overhead.
To eliminate this warning, add "type": "module" to /Users/ethan/dev/harperdb/harperdb/package.json.
SyntaxError: The requested module 'lmdb' does not provide an export named 'Transaction'
    at ModuleJobSync.runSync (node:internal/modules/esm/module_job:385:37)
    at ModuleLoader.importSyncForRequire (node:internal/modules/esm/loader:363:47)
    at loadESMFromCJS (node:internal/modules/cjs/loader:1569:24)
    at Module._compile (node:internal/modules/cjs/loader:1721:5)
    at Object.loadTS [as .ts] (node:internal/modules/cjs/loader:1831:10)
    at Module.load (node:internal/modules/cjs/loader:1473:32)
    at Function._load (node:internal/modules/cjs/loader:1285:12)
    at TracingChannel.traceSync (node:diagnostics_channel:322:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:234:24)
    at Module.require (node:internal/modules/cjs/loader:1495:12)
2025-01-14T17:11:39.050Z [main/0] [error]: SyntaxError: The requested module 'lmdb' does not provide an export named 'Transaction'
    at ModuleJobSync.runSync (node:internal/modules/esm/module_job:385:37)
    at ModuleLoader.importSyncForRequire (node:internal/modules/esm/loader:363:47)
    at loadESMFromCJS (node:internal/modules/cjs/loader:1569:24)
    at Module._compile (node:internal/modules/cjs/loader:1721:5)
    at Object.loadTS [as .ts] (node:internal/modules/cjs/loader:1831:10)
    at Module.load (node:internal/modules/cjs/loader:1473:32)
    at Function._load (node:internal/modules/cjs/loader:1285:12)
    at TracingChannel.traceSync (node:diagnostics_channel:322:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:234:24)
    at Module.require (node:internal/modules/cjs/loader:1495:12)

Activity

  1. marco-ippolito commented on Jan 14, 2025

    @marco-ippolito
    marco-ippolito
    on Jan 14, 2025
    Member

    99% of the time is because you are importing a type or interface without the type keyword.
    Amaro has nothing to do with it.
    This is not a parsing error which is all amaro does.
    Check in your code where you are importing Transaction and change it to type Transaction

    @JakobJingleheimer can your codemod fix this?

  2. Ethan-Arrowood commented on Jan 14, 2025

    @Ethan-Arrowood
    Ethan-Arrowood
    on Jan 14, 2025
    ContributorAuthor

    Yes the solution is quite easy and not hard to fix. My point of the issue is that why is this syntax error not stating which file the issue is coming from? If its not amaro, would this be a Node.js loader thing? Where might the best place for this issue be?

  3. Ethan-Arrowood commented on Jan 14, 2025

    @Ethan-Arrowood
    Ethan-Arrowood
    on Jan 14, 2025
    ContributorAuthor

    Here is another example:

    SyntaxError [ERR_INVALID_TYPESCRIPT_SYNTAX]:   x TypeScript parameter property is not supported in strip-only mode
     ,-[141:1]
 138 |     sessionResolve: Function;
 139 |     sessionReject: Function;
 140 |     constructor(
 141 |         public url: string,
     :                ^^^^^^^^^^^
 142 |         public subscription: any,
 143 |         public databaseName: string,
 144 |         public nodeName?: string,
     `----
  x TypeScript parameter property is not supported in strip-only mode
     ,-[142:1]
 139 |     sessionReject: Function;
 140 |     constructor(
 141 |         public url: string,
 142 |         public subscription: any,
     :                ^^^^^^^^^^^^^^^^^
 143 |         public databaseName: string,
 144 |         public nodeName?: string,
 145 |         public authorization?: string
     `----
  x TypeScript parameter property is not supported in strip-only mode
     ,-[143:1]
 140 |     constructor(
 141 |         public url: string,
 142 |         public subscription: any,
 143 |         public databaseName: string,
     :                ^^^^^^^^^^^^^^^^^^^^
 144 |         public nodeName?: string,
 145 |         public authorization?: string
 146 |     ) {
     `----
  x TypeScript parameter property is not supported in strip-only mode
     ,-[144:1]
 141 |         public url: string,
 142 |         public subscription: any,
 143 |         public databaseName: string,
 144 |         public nodeName?: string,
     :                ^^^^^^^^^^^^^^^^^
 145 |         public authorization?: string
 146 |     ) {
 147 |         super();
     `----
  x TypeScript parameter property is not supported in strip-only mode
     ,-[145:1]
 142 |         public subscription: any,
 143 |         public databaseName: string,
 144 |         public nodeName?: string,
 145 |         public authorization?: string
     :                ^^^^^^^^^^^^^^^^^^^^^^
 146 |     ) {
 147 |         super();
 148 |         this.nodeName = this.nodeName ?? urlToNodeName(url);
     `----

    at parseTypeScript (node:internal/modules/typescript:52:11)
    at processTypeScriptCode (node:internal/modules/typescript:98:42)
    at stripTypeScriptModuleTypes (node:internal/modules/typescript:132:10)
    at Object.getFileProtocolModuleFormat [as file:] (node:internal/modules/esm/get_format:146:26)
    at defaultGetFormat (node:internal/modules/esm/get_format:209:36)
    at defaultLoadSync (node:internal/modules/esm/load:176:14)
    at #loadAndMaybeBlockOnLoaderThread (node:internal/modules/esm/loader:751:12)
    at #loadSync (node:internal/modules/esm/loader:773:49)
    at ModuleLoader.getModuleJobForRequire (node:internal/modules/esm/loader:412:38)
    at new ModuleJobSync (node:internal/modules/esm/module_job:342:34) {
  code: 'ERR_INVALID_TYPESCRIPT_SYNTAX'
}

    Like yes I can search-replace here to find where these are, but also its a bit of a chore (and can be misleading) in a large code base. I'd rather these errors just contain the file path at least.

  4. marco-ippolito commented on Jan 14, 2025

    @marco-ippolito
    marco-ippolito
    on Jan 14, 2025
    Member

    Here is another example:

    SyntaxError [ERR_INVALID_TYPESCRIPT_SYNTAX]:   x TypeScript parameter property is not supported in strip-only mode
     ,-[141:1]
 138 |     sessionResolve: Function;
 139 |     sessionReject: Function;
 140 |     constructor(
 141 |         public url: string,
     :                ^^^^^^^^^^^
 142 |         public subscription: any,
 143 |         public databaseName: string,
 144 |         public nodeName?: string,
     `----
  x TypeScript parameter property is not supported in strip-only mode
     ,-[142:1]
 139 |     sessionReject: Function;
 140 |     constructor(
 141 |         public url: string,
 142 |         public subscription: any,
     :                ^^^^^^^^^^^^^^^^^
 143 |         public databaseName: string,
 144 |         public nodeName?: string,
 145 |         public authorization?: string
     `----
  x TypeScript parameter property is not supported in strip-only mode
     ,-[143:1]
 140 |     constructor(
 141 |         public url: string,
 142 |         public subscription: any,
 143 |         public databaseName: string,
     :                ^^^^^^^^^^^^^^^^^^^^
 144 |         public nodeName?: string,
 145 |         public authorization?: string
 146 |     ) {
     `----
  x TypeScript parameter property is not supported in strip-only mode
     ,-[144:1]
 141 |         public url: string,
 142 |         public subscription: any,
 143 |         public databaseName: string,
 144 |         public nodeName?: string,
     :                ^^^^^^^^^^^^^^^^^
 145 |         public authorization?: string
 146 |     ) {
 147 |         super();
     `----
  x TypeScript parameter property is not supported in strip-only mode
     ,-[145:1]
 142 |         public subscription: any,
 143 |         public databaseName: string,
 144 |         public nodeName?: string,
 145 |         public authorization?: string
     :                ^^^^^^^^^^^^^^^^^^^^^^
 146 |     ) {
 147 |         super();
 148 |         this.nodeName = this.nodeName ?? urlToNodeName(url);
     `----

    at parseTypeScript (node:internal/modules/typescript:52:11)
    at processTypeScriptCode (node:internal/modules/typescript:98:42)
    at stripTypeScriptModuleTypes (node:internal/modules/typescript:132:10)
    at Object.getFileProtocolModuleFormat [as file:] (node:internal/modules/esm/get_format:146:26)
    at defaultGetFormat (node:internal/modules/esm/get_format:209:36)
    at defaultLoadSync (node:internal/modules/esm/load:176:14)
    at #loadAndMaybeBlockOnLoaderThread (node:internal/modules/esm/loader:751:12)
    at #loadSync (node:internal/modules/esm/loader:773:49)
    at ModuleLoader.getModuleJobForRequire (node:internal/modules/esm/loader:412:38)
    at new ModuleJobSync (node:internal/modules/esm/module_job:342:34) {
  code: 'ERR_INVALID_TYPESCRIPT_SYNTAX'
}

    Like yes I can search-replace here to find where these are, but also its a bit of a chore (and can be misleading) in a large code base. I'd rather these errors just contain the file path at least.

    Yeah those are node core issues, we might have to trim the stacktrace. Amaro just throws an errors, the caller (Node) is responsible for stacktrace.

  5. JakobJingleheimer commented on Jan 15, 2025

    @JakobJingleheimer
    JakobJingleheimer
    on Jan 15, 2025
    Member

    99% of the time is because you are importing a type or interface without the type keyword.
    Amaro has nothing to do with it.
    This is not a parsing error which is all amaro does.
    Check in your code where you are importing Transaction and change it to type Transaction

    @JakobJingleheimer can your codemod fix this?

    Yes, I think so

    https://github.com/nodejs/userland-migrations/tree/main/recipes/correct-ts-specifiers

    The publication to codemod is not quite working yet, but you can run it via node like

    $ node path/to/correct-ts-specifiers/src/workflow.ts

    You'll need to install correct-ts-specifiers' deps

  6. JakobJingleheimer commented on Jan 15, 2025

    @JakobJingleheimer
    JakobJingleheimer
    on Jan 15, 2025
    Member

    Here is another example:

    SyntaxError [ERR_INVALID_TYPESCRIPT_SYNTAX]:   x TypeScript parameter property is not supported in strip-only mode
     ,-[141:1]
 138 |     sessionResolve: Function;
 139 |     sessionReject: Function;
 140 |     constructor(
 141 |         public url: string,
     :                ^^^^^^^^^^^
 142 |         public subscription: any,
 143 |         public databaseName: string,
 144 |         public nodeName?: string,

    For this, you need a different userland-migration (currently WIP): nodejs/userland-migrations#21

  7. marco-ippolito commented on Jan 27, 2025

    @marco-ippolito
    marco-ippolito
    on Jan 27, 2025
    Member

    Also typechecker should warn you if you use verbatimModuleSyntax

  8. marco-ippolito
    changed the title [-]Feedback: Provide more information when there is a SyntaxError[/-] [+]Provide more information when there is a SyntaxError[/+] on Jan 30, 2025

  9. marco-ippolito commented on Jan 30, 2025

    @marco-ippolito
    marco-ippolito
    on Jan 30, 2025
    Member

    Moving this issue to nodejs/node, it refs swc-project/swc#9884.
    I'm planning to include the location in the file where the error is generated.

  10. marco-ippolito
    transferred this issue fromnodejs/amaroon Jan 30, 2025
  11. marco-ippolito
    added
    strip-typesIssues and PRs related to TypeScript type stripping.
    on Jan 30, 2025

  12. marco-ippolito commented on Mar 26, 2025

    @marco-ippolito
    marco-ippolito
    on Mar 26, 2025
    Member

    This PR will fix the issue #57598 as the filename and line will be correctly included in the error

  13. nodejs-github-bot
    closed this as completedin e5ff731on Apr 1, 2025
  14. nodejs-github-bot
    added a commit that references this issue on Apr 1, 2025

    module: improve typescript error message format

    1c2d98d
  15. dnalborczyk
    added a commit that references this issue on Apr 1, 2025

    deps: update amaro to 0.5.0

    e5ff731

  16. 1 remaining item

  17. RafaelGSS
    added 4 commits that reference this issue on May 1, 2025

    deps: update amaro to 0.5.0

    0729bbc

    module: improve typescript error message format

    6cacc36

    deps: update amaro to 0.5.0

    a561755

    module: improve typescript error message format

    1e490aa
  18. RafaelGSS
    added 2 commits that reference this issue on Jul 15, 2025

    module: improve typescript error message format

    fe7994e

    deps: update amaro to 0.5.0

    25f8682
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

    strip-typesIssues and PRs related to TypeScript type stripping.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions