Skip to content

Generic warnings and hints mechanism #1445

@cspotcode

Description

@cspotcode

Extracted from #1248

Big idea: there are various places in ts-node where we can emit warnings and hints. We should have a generic mechanism to give them diagnostic codes and let users opt-in or opt-out either fully or per-code.


We discussed this on Discord: https://discord.com/channels/508357248330760243/508357707602853888/843546169752813589

Conclusions:

  • Use node's warnings API: process.emitWarning()
    • there is already precedent for warnings to emit to stderr from here
    • node already has APIs to intercept these warnings and flags to suppress them
  • Match node's behavior and emit each warning only once
  • Add warnings: boolean to API surface
    • false to disable them
    • Future work can expand to suppress or allow warnings by code
  • Add onWarning: callback to API surface
    • if specified, warnings are sent here instead of to process.emitWarning
  • All warnings get a code TSNODE<4-digit number>
    • This is familiar: node's deprecation warnings are DEP1234; TypeScript uses TS1234
    • code allows easy detection in process.on('warning' handlers
  • emit to stderr, not stdout
    • changes to stderr emit typically not considered breaking; stderr has no contract

Questions

  • when tsconfig has "warnings": false, but a warning emits before tsconfig is loaded
    • Do we defer those warnings till after all options are known? For the "target" warning, we can do this
  • ts-node's existing diagnostic logging: does it get diagnostic codes?
  • diagnostic code types
    • warning
    • hint
    • debug / trace
  • TS_NODE_DEBUG or DEBUG env var
    • support full range of include / exclude config supported in tsconfig?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions