Closed Brendonovich closed 6 months ago
Yeah we can look at adding a build process. This was a big problem for some projects in the previous version. But there is a lot less code here and while others working on this project might be all for JSDoc .. while I like the result, I generally am not.
There is some tension between the code needed for runtime and the code needed for build time. I need to make sure there isn't cross referencing in a weird way but this should be doable I think.
I was informed this would be problematic for things like the dev overlay. So I'm not sure how feasible this is at this time. I'm not the greatest with typescript and the other developers who contribute the most to the project have been pushing back from having a build process.
That's understandable, but I just want to emphasize how unconventional this setup is. I've worked in a lot of different code bases with tons of different frameworks, and never have I seen a package that ships like this, with type issues in the package itself affecting the end user. Most projects I have worked on enforce passing tsc
in CI, meaning a solid-start project would not make it out the door. I do it myself for my hobby projects as well, and for solid-start I consider it okay because of the beta label, but if this is the intended end state for 1.0 as well I'm not sure I'll keep using solid-start. And please read this the right way, I absolutely love solid-start, but this kills my whole workflow which relies a lot on running tsc -w
continuously while developing.
I don't have a lot of experience with publishing packages, but these are some ways forward that could alleviate this issue that I can come up with:
Just my 5 cents as a solid-js user since 3 years who really wants solid-start to succeed! π
I think i've managed to add a simple build process using tsc
and some file copying.
It's available on npm under @brendonovich/solid-start
and the code is on my fork
Implemented in 0.7.2. Thanks @Brendonovich for the leg work here.
Duplicates
Latest version
Current behavior π―
@solidjs/start
currently points to.ts
and.tsx
files for resolving type information.Using source
.ts
files makesskipLibCheck
ineffective, leading to errors like thisExpected behavior π€
.d.ts
files should be built and pointed to intypes
,exports
andtypesVersions
inpackage.json
. Source files should still be pointed to for conditional exports such asimport
andexport
. Prior art includes Solid Router and Kobalte.Steps to reproduce πΉ
Steps:
pnpm tsc
@solidjs/router
even thoughskipLibCheck
is enabledContext π¦
I like doing monorepo-wide typechecking with
pnpm tsc -b
, but these errors get in the way. I can just run the command from packages that don't depend on@solidjs/start
in the meantime.Your environment π
No response