Challenges from migrating another large project

[lexanth]

I've been trying out Snowpack on two large (related) projects and like #1387 I had some challenges that I thought it might be useful to share. Some of these may be bugs, others could lead to feature requests. I've not managed to get it fully working yet though.

1. Non-transpiled packages

For various reasons, one of the projects uses a group of internal NPM packages which are published as untranspiled typescript source. In webpack, this is just handled by a regex in the rule for babel-loader to include packages in our scope.

In Snowpack, I managed to get them to transpile by adding mounts for each package

mount: {
    public: { url: '/', static: true },
    src: { url: '/dist' },
    '/node_modules/@ourscope/pkg1': '/@ourscope/pkg1',
    // ...etc (actually did it with mapping over an array)
}

But when @ourscope/pkg2 depends on @ourscope/pkg1 it was trying to fetch from /_snowpack/pkg/@ourscope.pkg1.xxx rather than using the transpiled version (definitely had a single version of each @ourscope package installed, not nested versions in each other's node_modules. This blocked me on one of the projects.

2. Type-only imports

As described in #1387 we also have a lot of type-only imports which disappear at runtime. We also have the same for a load of mixed type/value exports

export { MyComponent, IMyComponentProps } from './MyComponent';

which seemed to cause issues with complaints of MyComponent not having an IMyComponentProps export at runtime.

2a. Type-only files

Similarly, we have quite a few types.ts files which don't exist at runtime because they only have types, so you get an error from the browser failing to fetch it, rather than for the import not existing at runtime. Again, could be fixed by us (make them types.d.ts and make the imports type imports), but it's a big job.

Potentially if this happens Snowpack could just emit a file with an empty export? I think swc was looking at doing that.

3. Clashes between files with different extensions

We use GraphQL with operations defined in .graphql files. I added snowpack-plugin-graphql to handle this, but then hit an issue from filenames clashing.
We sometimes/often have MyComponent.tsx and MyComponent.graphql alongside (and MyComponent.module.scss for that matter). MyComponent.tsx and MyComponent.graphql both try to output MyComponent.js so conflict. I tried tweaking the plugin to output the graphql files as .graphql.js but it seemed like it wasn't rewriting the imports properly to use that extension. I'm not sure if the plugin system can currently handle this?

Again, could be sorted by exhaustively going through and renaming files to not clash, but would be nice to have a way to make this work without that.

4. Failing to find exports on some external dependencies

The requested module '../../../../../pkg/@toast-ui.react-editor.v2.3.1.js' does not provide an export named 'Viewer'

@toast-ui/react-editor doesn't seem to be scanned properly for exports (we have import { Viewer } from '@toast-ui/react-editor';). I also saw similar with scheduler.

This last one blocked me getting any further though.

If anyone has any suggestions for any of these, I'd be happy to try them out - otherwise I hope this is useful feedback. I'd love to get it up and running and try out the exciting dev experience promises in a sizeable project!

[jugglingcats]

Have same issue as your item 4. Downgraded to Snowpack 3.0.13 (our original Snowpack installed version) and it worked for me