export * and typescript statements only files => 404

[terlenbach]

Hello! First of all congratulations for the amazing work on Snowpack, I've been using it for almost a month now and it's truly boosting my productivity.

I've recently tried to add some code generated by openapi generator and the typescript-rxjs generator, and that basically broke my snowpack build. After some digging, I managed to understand (more or less) what was happening and I also could put in place a minimal working example for reproducing the problem: https://github.com/terlenbach/snowpack_404.

Some explanations: there is an index.ts file which exports everything from some other files, these other files sometimes contain real code, and sometimes only typescript definitions. The index.ts is compiled into a JS file which will try to load all the referenced modules, but it looks like the esbuild output for the file that contains only typescript statements is just empty and then snowpack won't create any js file, which makes the app fail because of a 404 error.

This patch fixes the problem:

diff --git a/snowpack/src/plugins/plugin-esbuild.ts b/snowpack/src/plugins/plugin-esbuild.ts
index ecc436f2..b3662833 100644
--- a/snowpack/src/plugins/plugin-esbuild.ts
+++ b/snowpack/src/plugins/plugin-esbuild.ts
@@ -44,7 +44,7 @@ export function esbuildPlugin(config: SnowpackConfig, {input}: {input: string[]}
       }
       return {
         '.js': {
-          code: code || '',
+          code: code || 'Empty file, only typescript statements?',
           map,
         },
       };

but I feel that we can do way better than this. WDYT?

[dgreensp]

I just started using Snowpack, and I always use index.ts files with export * from ... in my projects. I'm kind of shocked; is there a workaround, or does Snowpack just not support this?

Edit: Oh, I see, export * is implemented correctly. The problem is more with files that contain only types that are pulled in by the export *. So this should be a pretty easy fix, hopefully.

[dgreensp]

Workaround, add this line (last line) to all your files that happen to be type-only :)

export interface Reporter {
  log: (message: string) => void;
}

const _SNOWPACK = true; // https://github.com/snowpackjs/snowpack/discussions/1589

[aryzing]

Ran into the same problem, and solution 😂. If you're using a linter that complains about unused variables, just make sure you export it 😉.

If snowpack could support this corner case, that would be great! In any case, congrats on the project, it's great!

[rainmanhhh]

what about generated files? (my apis are generated by openapi-generator and lots of files only contains interfaces)

[joswarmer]

In also needed to export a const named Reporter, because this symbol is being exported in internal.js.

[TylorS]

This is a pretty serious issue IMO. It doesn't make much sense to add arbitrary things to your files.

[thsorens]

I also came over this today. Adding snowpack specific stuff to each file is just not an option.

[TylorS]

FWIW, I've switched over to Vite for the time being. It was a fairly painless switch

[thsorens]

How is the support for yarn workspaces? I finally got that working with snowpack :P

[TylorS]

I've just been using npm here for the last few years, so I'm not really sure. A quick search landed me here

• Support Yarn Workspaces with Yarn PnP mode / Comprehensive Monorepo Support vitejs/vite#195

It seems like they have first-class support for it since v0.20.0, but it seems relatively manual then. However, in Vite 2 it looks like they've also added parsing of your package.json dependencies

• Help with monorepo vitejs/vite#1491 (comment)

I dunno if all of this meets your expectations, but I hope it helps 😄

[BPScott]

This is fixed in the 3.1.0 prereleases being tested out in #2707. See this conversation starting https://github.com/snowpackjs/snowpack/pull/2707#issuecomment-786406311 for more info

[lgarron]

This is fixed in the 3.1.0 prereleases being tested out in #2707. See this conversation starting https://github.com/snowpackjs/snowpack/pull/2707#issuecomment-786406311 for more info

Should this be working yet?

I'm trying out Snowpack, and it's tripping on this file:
https://github.com/cubing/cubing.js/blob/9c46aa54e1209a9b3c997bb0ab80d8af3870b69c/src/cubing/alg/units/Unit.ts

(That should actually be a d.ts file, but it's a .ts file instead because of bugs in other bundlers.)

P.S. I think the link text and URL in your comment are swapped.

[lgarron]

Oh, it seems to be complaining that this line is exporting a value that doesn't exist:

https://github.com/cubing/cubing.js/blob/9c46aa54e1209a9b3c997bb0ab80d8af3870b69c/src/cubing/alg/units/index.ts#L8

... because it's a type, so it's gone after the compile.

Apparently using export type for that line works, but it's a little uncomfortable that perfectly normal TypeScript causes Snowpack to trip over. :-/

(It's not so easy to avoid an accidental value-export of a type definition. There's importsNotUsedAsValues for TypeScript, but I'm not familiar with something similar for exports.)

[BPScott]

@lgarron set isolatedModules: true in your tsconfig - it is designed to identify these issues.

it's a little uncomfortable that perfectly normal TypeScript causes Snowpack to trip over. :-/

This is because the Snowpack transpiles single files at a time, while by default tsc looks at a whole project. See the ts docs above for more info.

For more context see: #3016 and https://www.snowpack.dev/reference/common-error-details#uncaught-syntaxerror%3A-the-requested-module-%E2%80%98.%2Fxxxxxx.js%E2%80%99-does-not-provide-an-export-named-%E2%80%98yyyyyy%E2%80%99

[brightblade42]

This seems like a huge problem. I just moved from webpack to snowpack and I'm running into this issue which leaves me dead in the water. The current fix is to add some workaround code to the offending ts files but what about libs that I don't control. I'm supposed to fork any ts project that causes snowpack to fail? Am I misunderstanding the issue?

[rainmanhhh]

try vite