Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing noEmit: true from default tsconfig.json in type stripping docs #57294

Closed
styfle opened this issue Mar 3, 2025 · 8 comments · Fixed by #57320
Closed

Missing noEmit: true from default tsconfig.json in type stripping docs #57294

styfle opened this issue Mar 3, 2025 · 8 comments · Fixed by #57320
Labels
doc Issues and PRs related to the documentations.

Comments

@styfle
Copy link
Member

styfle commented Mar 3, 2025

Affected URL(s)

https://nodejs.org/api/typescript.html#type-stripping

Description of the problem

The recommended tsconfig.json is missing noEmit: true.

Is seems very likely that a user who chooses to author in TS over JS will also want to type check their code.

And if you forget noEmit: true, then you'll accidentally emit JS, which is not needed.

@styfle styfle added the doc Issues and PRs related to the documentations. label Mar 3, 2025
@styfle
Copy link
Member Author

styfle commented Mar 3, 2025

cc @marco-ippolito @nodejs/typescript in case there is a reason this was omitted. I search existing issues and prs but didn't find a reason.

I can create a PR if we want to add, noEmit: true, just let me know 🤓

@marco-ippolito
Copy link
Member

Since the feature is experimental we'd want to encourage users to transpile, and I generally Id always encourage users to transpile 😆

@robpalme
Copy link
Contributor

robpalme commented Mar 3, 2025

I think there's two separate use-cases that we cannot express in a single tsconfig.json.

  1. Always directly execute source (noEmit)
    • This will work fine for simple things like build scripts written as *.ts files that will never need to be distributed/published.
  2. Situational execution (rewriteRelativeImportExtensions)
    • During development: Direct execution of source
    • For production/publication: Compile-to-JS

IMO both use-cases are legitimate. Use-case 1 (that @styfle is referring to) is simpler so some folk might prefer it.

@styfle
Copy link
Member Author

styfle commented Mar 3, 2025

simple things like build scripts written as *.ts files that will never need to be distributed/published

This is exactly the case I ran into.

I have a large build script in JS and it had a bug so I wanted to convert to TS to catch the bug for future authors. Perfect use case for strip types. But then after following the docs, I realized it was emitting JS 😓

I guess I'm having trouble understanding the other use case of why strip types if you plan to use tsc to transpile?

@marco-ippolito
Copy link
Member

marco-ippolito commented Mar 3, 2025

I guess I'm having trouble understanding the other use case of why strip types if you plan to use tsc to transpile?

faster development cycle, no need to wait for tsc to transpile as you develop
We could propose two config, one for transpiling one for not traspiling

@styfle
Copy link
Member Author

styfle commented Mar 3, 2025

Yeah two configs might work. Or one config with an optional comment like:

{
  "compilerOptions": {
     "noEmit": true, // Optional - prevent tsc from emitting transpiled JS
     "target": "esnext",
     "module": "nodenext",
     "allowImportingTsExtensions": true,
     "rewriteRelativeImportExtensions": true,
     "erasableSyntaxOnly": true,
     "verbatimModuleSyntax": true
  }
} 

I can create a PR after #57271 merges.

@jakebailey
Copy link

Yeah, I would just include a note, though I would suggest making it mention "if you are publishing" or something.

@styfle
Copy link
Member Author

styfle commented Mar 4, 2025

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc Issues and PRs related to the documentations.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants