[Bug]TypeError: preact_render_to_string_1.renderToString is not a function

[strrchr]

When using ts-node.

[marvinhagemeister]

Please post your tsconfig.json if one is present in your project and how you're importing preact-render-to-string. We don't see what's on your screen so we need a little more information ;)

I've been using ts-node with preact-render-to-string myself in quite a few projects without issues. So I'm guessing there either is a combination of a configuration error in tsconfig.json and the way preact-render-to-string is imported.

[pavel-klimov]

I have same problem with default nest.js project. It have that tsconfig.json:

{
  "compilerOptions": {
    "module": "commonjs",
    "declaration": true,
    "removeComments": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "allowSyntheticDefaultImports": true,
    "target": "es2017",
    "sourceMap": true,
    "outDir": "./dist",
    "baseUrl": "./",
    "incremental": true
  }
}

[lemonmade]

I think this has to do with the way the non-ESM version of this package is published. That version ends up only exporting the "default" export from the library (https://cdn.jsdelivr.net/npm/preact-render-to-string@5.1.20/dist/index.js), which excludes all the additional named exports. You can see the problem in the Node REPL for a project with type: "module" that depends on preact-render-to-string:

[marvinhagemeister]

This makes a strong argument in favor of removing the default export all together. With only named exports we'd ensure that our lib can be used the same way across module systems and avoid the issues surrounding default exports in different module systems entirely.

[toverux]

Stumbled upon this too.
Had to use the default import and not the named variant.

This makes a strong argument in favor of removing the default export all together.

Yes, default imports are also not very liked today, and unpractical to use. Some consider it as being a bad practice. I think they only make perfect sense when importing non-JS things/unstructured data with module bundlers, otherwise they probably should be avoided as it's mostly detrimental to DX (when it doesn't causes problems with non-ESM environments, like here).