I'm not sure if this is something you'd consider @lorenwest, but I was having issues working with TypeScript and node-config in my esm project. I was able to patch tsx into node-config and it made it so I was able to load my TypeScript configurations regardless if my project was an esm project or commonjs.

Thank you for bringing this to our attention. That sounds like a healthy option to support. Do you have any ideas about how an installation would choose tsx over ts-node? Maybe an environment variable or something? Or maybe an attempt to require tsx with a fallback to ts-node (assuming 100% compatibility)?

It has to run with current installations, so the default may have to be ts-node. This project doesn't include the parser dependencies so if we just switched it to tsx it would break existing installs that don't have that library installed.

So that's why I'm not super dedicated to this approach. tsx uses es-build under the hood which isn't 100% compatible with tsc/TypesScript. For example es-build does not and will not support emitDecoratorMetadata and other deep type reflection features. Hopefully since node-config is only loading config files they wouldn't need those kinds of complicated features, but I'm sure there's someone out there who's doing some wild stuff in their default.ts.

Maybe this can be adapted so that ts-node is tried first, but then it falls back to tsx if ts-node can't transpile the file or something? Alternatively, the documentation could instruct users to install which ever library they prefer and node-config could try each and use whatever works first? Probably with ts-node being tried first as it has been the method used for so long?

I'm not super sure what the best approach is as I don't have much history with this project and wouldn't want to introduce something that's against the goals/style here. Thanks for taking a look though, and happy to bring tsx to your attention. I think it's a pretty neat project!

Leaving open if any contributors want to take on this issue.

I am not familiar with tsx and am neutral on this proposal.

TypesScript. For evanw/esbuild#257 and other deep type reflection features.

Is that a bad thing in a config library? Least Power suggests to me that reflection in load time logic might be a bridge too far. I could see a case for this being a wontfix.

Do you know if this plays nice with nyc? If so then I’m on board. Does it make #740 worse, better, indifferent? Could you take a stab at updating the readme to reflect this caveat?

Do you know if this plays nice with nyc?

Sadly, no.

SyntaxError: Missing initializer in const declaration

I was hoping for advice from the Istanbul people but no luck so far

istanbuljs/nyc#1595

See #847

Depending on how this ticket plays out, we may need to overlook the downsides of this solution.

@lorenwest @markstos

nodejs/node#59364

FYI, just ran into an issue (I belive nodejs/node#59364 referenced above) when trying to use native ts support after upgrading node from 22.17 to 22.18.

I load config/default.ts when import config from 'config'; occurs in the codebase.
The error I got after updating to node 22.18 was:

Error: Cannot parse config file: '<PROJECT_PATH>/config/default.ts': Error: Must use import to load ES Module: <PROJECT_PATH>/config/default.ts
require() of ES modules is not supported.
require() of <PROJECT_PATH>/config/default.ts from <PROJECT_PATH>/node_modules/config/parser.js is an ES module file as it is a .ts file whose nearest parent package.json contains "type": "module" which defines all .ts files in that package scope as ES modules.
Instead change the requiring code to use import(), or remove "type": "module" from <PROJECT_PATH>/package.json.

I made a wrapper config/default.js with:

import c from './defaultConfig.ts';
export default c;

This avoids require() on the config file with the unmaintained ts-node and uses node's amaro's type stripping instead.
tsx would have worked as well, but this way it's not really required as a dependency given node is capable of "running" ts today.

Maybe you could somehow work this into your lib?