solid-start: [Bug?]: New solid start doesn't work with yarn berry

Duplicates

  • I have searched the existing issues

Latest version

  • I have tested the latest version

Current behavior 😯

daniel@mmmmmmmmmm my-app % yarn
➀ YN0000: · Yarn 4.0.2
➀ YN0000: β”Œ Resolution step
➀ YN0082: β”‚ @esbuild/android-arm64@npm:0.19.10: No candidates found
➀ YN0000: β”” Completed in 1s 720ms
➀ YN0000: · Failed with errors in 1s 730ms

Expected behavior πŸ€”

yarn install should complete successfully

Steps to reproduce πŸ•Ή

Follow this terminal log:

daniel@mmmmmmmmmm test % npm init solid@latest
Need to install the following packages:
create-solid@0.4.2
Ok to proceed? (y) y

create-solid version 0.4.0-alpha.0

Welcome to the SolidStart setup wizard!

There are definitely bugs and some feature might not work yet.
If you encounter an issue, have a look at https://github.com/solidjs/solid-start/issues and open a new one, if it is not already tracked.

βœ” Where do you want to create the app? … my-app
βœ” Which template do you want to use? β€Ί bare
βœ” Server Side Rendering? … yes
βœ” Use TypeScript? … yes
found matching commit hash: be388d58737ced31b0ed78cd8128f83c2b0a319b
downloading https://github.com/solidjs/solid-start/archive/be388d58737ced31b0ed78cd8128f83c2b0a319b.tar.gz to /Users/daniel/.degit/github/solidjs/solid-start/be388d58737ced31b0ed78cd8128f83c2b0a319b.tar.gz
extracting /examples/bare from /Users/daniel/.degit/github/solidjs/solid-start/be388d58737ced31b0ed78cd8128f83c2b0a319b.tar.gz to /private/tmp/test/my-app/.solid-start
cloned solidjs/solid-start#main to /private/tmp/test/my-app/.solid-start
βœ” Copied project files

Next steps:
  1: cd my-app
  2: npm install
  3: npm run dev -- --open

To close the dev server, hit Ctrl-C
^C
daniel@mmmmmmmmmm test % cd my-app 
daniel@mmmmmmmmmm my-app % rm -rf node_modules package-lock.json 
daniel@mmmmmmmmmm my-app % yarn set version berry
warning package.json: No license field
(node:22152) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
➀ YN0000: Retrieving https://repo.yarnpkg.com/4.0.2/packages/yarnpkg-cli/bin/yarn.js
➀ YN0000: Saving the new release in .yarn/releases/yarn-4.0.2.cjs
➀ YN0000: Done in 0s 675ms
daniel@mmmmmmmmmm my-app % yarn
➀ YN0000: · Yarn 4.0.2
➀ YN0000: β”Œ Resolution step
➀ YN0082: β”‚ @esbuild/android-arm64@npm:0.19.10: No candidates found
➀ YN0000: β”” Completed in 4s 230ms
➀ YN0000: · Failed with errors in 4s 238ms

Context πŸ”¦

I want to use the latest version of yarn which is fast and also supports yarn link so I can link my locally built packages.

Your environment 🌎

Node v21.5.0 on macOS 14.2.1 (23C71)
M1 Max 16" MacBook Pro

About this issue

  • Original URL
  • State: open
  • Created 6 months ago
  • Reactions: 1
  • Comments: 54 (51 by maintainers)

Most upvoted comments

it seems like I was able to reproduce your error when using the bare template. What I have been able to run so far was the basic template that includes the router (apparently didn’t read your reproduction steps closely enough, but it became clear by comparing to the zip you shared).

I don’t know how much loading speed will be helped by making config a type only util. The things it imports (mostly lazily) are also going to be imported anyway during load to start the app. Make the entry point runnable is desirable for an architecture that is meant to be totally in the users control.

Mlly and jiti are right now used for running typescript config files. I am probably going to go the way of vite and use esbuild to quickly transpile the config file … and then load that.

I would be happy to help investigating any upstream compatibility issues within UnJS ecosystem but highly appreciate making minimal reproductions to investigate πŸ™πŸΌ

https://github.com/nksaraf/vinxi/pull/60 should help with js config files.

Also is there something better I can use than jiti for loading our config files which might be ts? Should I go the vite route and bundle the config file with esbuild first?

@danieltroger , i think it could be… while it was needed initially, I find it’s increasingly starting to be more in the way, than actually being helpful as recognized here as well.