Expose typings to project code #68
Conversation
| let data: string; | ||
|
|
||
| try { | ||
| const result = await snowpack.loadUrl(url, {isSSR: true, encoding: 'utf-8'}); |
There was a problem hiding this comment.
Snowpack's typings show it should be utf8 rather than utf-8
| const consumer = new SourceMapConsumer(raw_sourcemap); | ||
| // TODO: according to typings, this code cannot work; | ||
| // the constructor returns a promise that needs to be awaited | ||
| const consumer = new (SourceMapConsumer as any)(raw_sourcemap); |
There was a problem hiding this comment.
this whole file doesn't seem to be used anyway (copied from sapper). can we just delete it?
There was a problem hiding this comment.
perhaps this is because Sapper uses 0.6.1 of source-map. I don't see a version specified in Kit except for source-map: 0.5.7 and source-map: 0.7.3 in pnpm-lock.yaml
before deleting this file we might want to test what happens if an error is thrown server-side in the production app. will the stacktrace be readable (i.e. sourcemapped) or will it be on the minimized code?
There was a problem hiding this comment.
True, it's a newer version; then the code most likely does indeed not work. It's non-trivial to change the code to be async, that's why I didn't do it. Should we downgrade in the meantime?
There was a problem hiding this comment.
On the stack traces: in dev mode, if I throw an exception in Nav.svelte, I get this on the server side:
Error: testing stacktrace
at eval (/_app/components/Nav.js:15:8)
at Object.$$render (/web_modules/svelte/internal.js:1343:22)
On the client side, it correctly says /Nav.svelte as location.
On a production build, the client-side stack trace from an error I throw in an on:click looks like this:
Uncaught Error: testing stacktraces
at HTMLButtonElement.<anonymous> (Nav.js:268)
(anonymous) @ Nav.js:268
The server-side stack traces look like:
Error: testing stacktrace
at fn (/Users/andreasehrencrona/projects/svelte/kit/examples/hn.svelte.dev/.svelte/build/unoptimized/server/_app/components/Nav.js:13:8)
Is this worth a ticket? I'm not sure what expectations we have; neither of the stack traces is terrible, but it would of course be better if it mentioned the correct source file.
There was a problem hiding this comment.
Yeah, we had to stick to 0.6.1 in Sapper because we hadn't figured out how to support newer versions yet
Yeah, it seems worth a ticket to source map the production server-side trace just as Sapper does today
| 'src/setup': '/_app/setup' | ||
| }, | ||
| alias: { | ||
| '@sveltejs/kit': '/_app/main', |
There was a problem hiding this comment.
Does this mean the user has to build once to make TS happy because else the typings don't exist yet?
There was a problem hiding this comment.
No, this configuration doesn't affect your development tools (this is the run-time module resolution). The (dev) dependency @sveltejs/kit already exists; so the development tools will look inside it for the typings and find them in the client/index.d.ts.
(It won't be able to resolve to the source code since it's only copied into place (in .svelte/build during the build)
|
Thanks — though I'm not certain we do want to expose I'll merge this regardless as it contains a bunch of other useful changes, but we should continue discussing that over on #58. |
@sveltejs/kit/client(so e.g.import { goto } from '@sveltejs/kit/client'works)tsconprepublishpackages/kitbuild withtscwithout errorsIt only builds typings for
packages/kit/src/clientsince this is presumably the only API we want to expose to project code.The generated client typing files need to be in the directory
clientfor them to be recognized. I would prefer them to be in e.g.typings, but I don't think there is currently any way to put them elsewhere if we want to generate the typings from source (as suggested by @dummdidumm and with which I agree). I spent quite some time trying to find away around this; this issue convinced me there probably isn't any.There are two
tsconfig.json: one inclientthat builds the typings for the project code and one inpackages/kitthat runstscover the entire code but doesn't output any build artefact (useful for checking for build warnings/errors).Building the typings slows down the build by three seconds on my Macbook Air 2019. We could move them out of
prepareif we don't want that and possibly put themprepublishOnlyinstead.Relates to #31