preact-render-to-string
preact-render-to-string copied to clipboard
[Bug]TypeError: preact_render_to_string_1.renderToString is not a function
When using ts-node.
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.
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
}
}
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/[email protected]/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
:
![Screen Shot 2022-03-23 at 6 07 50 PM](https://user-images.githubusercontent.com/3012583/159804487-d0b28508-7ea7-444f-9eec-db55f4360500.png)
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.
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).