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

Failed to create worker instance #696

Closed
vjpr opened this issue Oct 21, 2021 · 14 comments
Closed

Failed to create worker instance #696

vjpr opened this issue Oct 21, 2021 · 14 comments

Comments

@vjpr
Copy link

vjpr commented Oct 21, 2021

Issue description or question

Quokka #1 (node: v16.7.0, TypeScript: v4.5.0-beta, plugins: quokka-plugin-live)

Failed to create worker instance

How can I debug this? Can I see the logs somewhere?

Code editor version

IntelliJ IDEA 2021.2.3 (Ultimate Edition)

OS name and version

OSX

@vjpr
Copy link
Author

vjpr commented Oct 21, 2021

I added nativeEsm (my packages are using type: module), and it progressed past this message.

Also found that an undocumented debug option shows stack traces.


What does nativeEsm actually do?

I would prefer to use my own --experimental-loader to transpile without ts-node. Is there a way to do this?


Now I get this:

⨯ Unable to compile TypeScript:
node_modules/@live/scripts/tsconfig/tsconfig.base.json(77,25): error TS6046: Argument for '--moduleResolution' option must be: 'node', 'classic'.
	at createTSError ./node_modules/.pnpm/ts-node@10.2.1_typescript@4.5.0-beta/node_modules/ts-node/src/index.ts:692
	at reportTSError ./node_modules/.pnpm/ts-node@10.2.1_typescript@4.5.0-beta/node_modules/ts-node/src/index.ts:696
	at create ./node_modules/.pnpm/ts-node@10.2.1_typescript@4.5.0-beta/node_modules/ts-node/src/index.ts:707
	at Object.register ./node_modules/.pnpm/ts-node@10.2.1_typescript@4.5.0-beta/node_modules/ts-node/src/index.ts:485

I use this in my .quokka file in my IntelliJ project root. It doesn't seem to override.

{
  "ts": {
    "compilerOptions": {
      "moduleResolution": "node"
    }
  }

My tsconfig.json file is using something like:

{
  "extends": "./path/to/monorepo/tsconfig/tsconfig.json",
  "compilerOptions": {
    "moduleResolution": "nodenext" // This is only available in 4.5@beta I think.
  }
}

EDIT: Seems unsupported in ts-node at present. TypeStrong/ts-node#1414


Setting babel: true, doesn't seem to disable ts-node for me.

@smcenlly
Copy link
Member

Your original error, Failed to create worker instance is caused by ts-node not supporting TypeScript 4.5 beta. This should be fixed once ts-node adds support for it.

What does nativeEsm actually do?

For the purpose of supporting wider range of nodejs versions by default Quokka uses ECMAScript module loader. If you are using nodejs 12 or higher, then you may change your Quokka config to switch to native ECMAScript modules with:

{
  ...
  "stdEsm": false,
  "nativeEsm": true
}

I would prefer to use my own --experimental-loader to transpile without ts-node. Is there a way to do this?

We don't currently support this. If you're using native esm, Quokka actually creates and uses its own loader.

Setting babel: true, doesn't seem to disable ts-node for me.

From our docs:

If you want to use Babel to compile TypeScript files then an additional configuration option, ts is required to override Quokka’s default use of the TypeScript compiler. When using Babel to compile TypeScript files, Quokka will run your code using node instead of ts-node. An example configuration is shown below:

{
  "babel": {
    "ts": true,
    "plugins": ["@babel/plugin-transform-typescript"]
  }
}

@vjpr
Copy link
Author

vjpr commented Oct 22, 2021

We don't currently support this. If you're using native esm, Quokka actually creates and uses its own loader.

Does Quokka actually need to use its own loader to enable any Quokka functionality?

Would it be difficult to support disabling this? I want to use the same --experimental-loader I use for Wallaby, so I can compile with swc, but right now it seems I'm forced to use ts-node or babel, but not just plain node.

@smcenlly
Copy link
Member

Does Quokka actually need to use its own loader to enable any Quokka functionality?

Quokka needs the loader in order to be able to re-use the sample node.js process (this is what makes it fast).

We don't have any plans to support custom experimental loaders with Quokka at this point in time, and it's not a trivial change for us.

We are happy to add a feature request for supporting swc (not sure when we'd implement it); would that solve your problem or do you do more custom things with your own swc implementation that would not work?

@vjpr
Copy link
Author

vjpr commented Oct 22, 2021

or do you do more custom things with your own swc implementation that would not work?

It was quite complex to get it working with Wallaby so a lot of stuff related to that.

I prefer to be able to add my own hook so I can write better error messages when something goes wrong, and can debug/log module resolution.

Quokka plugins are used often to modify module loading, so this is just the same functionality for native ESM.

Quokka needs the loader

Doesn't ts-node need to install it's own loader too?

Even when running nativeEsm = true, ts-node is used.

@smcenlly
Copy link
Member

It was quite complex to get it working with Wallaby so a lot of stuff related to that.

Yeah, I had figured that adding swc support wouldn't work for you.

Doesn't ts-node need to install it's own loader too?

Quokka integrates with ts-node and its loader with the Quokka esm loader.

@vjpr
Copy link
Author

vjpr commented Oct 22, 2021

For SWC support, this might help: https://typestrong.org/ts-node/docs/transpilers#bundled-swc-integration

@vjpr
Copy link
Author

vjpr commented Oct 22, 2021

Also, does this work: https://quokkajs.com/docs/configuration.html#compiler-settings

It had not effect for me.

@smcenlly
Copy link
Member

For SWC support, this might help: https://typestrong.org/ts-node/docs/transpilers#bundled-swc-integration

Thanks!

Also, does this work: https://quokkajs.com/docs/configuration.html#compiler-settings

The TypeScript compiler setting is only applicable if you are using the TypeScript compiler. If you are using babel (which I assume that you're using) then you will need to perform similar configuration with babel config. From the babel docs:

The official TypeScript compiler has many options for configuring how it compiles and type checks. While many don't apply, some behaviors might be useful and their equivalents in Babel can be enabled by some configuration options or plugins.

@vjpr
Copy link
Author

vjpr commented Oct 22, 2021

The TypeScript compiler setting is only applicable if you are using the TypeScript compiler

Even with ts-node, it doesn't seem to do anything.

Ideally I don't want anything babel in my codebase anymore.

My blocker right now is ts-node complaining about unsupported configs. Can I specify a path to a tsconfig.json?

@smcenlly
Copy link
Member

Could you please provide your exact configuration? It works for us but perhaps there is something wrong with your config.

@vjpr
Copy link
Author

vjpr commented Oct 22, 2021

https://github.com/vjpr/issue-quokka-ts/tree/main

I think the issue is that it's not overriding options from the tsconfig.extends file.

@smcenlly
Copy link
Member

It looks like the problem is with TypeScript initially parsing the tsconfig.json file. If you test other properties (e.g. target) you will see that Quokka is working correctly.


I get the same error trying to compile your project from the CLI with TypeScript 4.5.0 beta:

> npx tsc --version
Version 4.5.0-beta

> npx tsc -p .     
tsconfig/tsconfig.json:3:25 - error TS6046: Argument for '--moduleResolution' option must be: 'node', 'classic'.

3     "moduleResolution": "nodenext"
                          ~~~~~~~~~~


Found 1 error.

@vjpr
Copy link
Author

vjpr commented Oct 23, 2021

Interesting. TS docs are wrong then...or maybe it's coming in new beta. https://www.typescriptlang.org/tsconfig#moduleResolution


Or maybe 'module' needs to be set to 'nodenext'. Docs are a bit confusing.


UPDATE: Yep, if you install typescript@next it works. The jsonschema was out of date.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants