Support src/node_modules/* for easy importing as used in Svelte/Sapper

[jthegedus]

Sapper uses src/node_modules/* for generated files as they can be imported without long relative paths. Given this pattern many Svelte/Sapper users have begun to use this pattern to store their own components etc to avoid relative imports or setup aliases in their entire tool stack (see sveltejs/sapper#551).

Snowpack seems unable to resolve modules within src/node_modules/*. I tried by:

npx create-snowpack-app app/ --template @snowpack/app-template-svelte
npm start

Then add to .gitignore:

.build
build
web_modules
node_modules
+!src/node_modules

Then add src/node_modules/@components/Test.svelte:

<script>
export let title = "default"
</script>

<h3>{title}</h3>

and try importing it in src/App.svelte:

<script>
+  import Test from "@components/Test.svelte";
  const message = "Learn Svelte";
</script>

<div class="App">
  <header class="App-header">
    <img src="/logo.svg" class="App-logo" alt="logo" />
    <p>Edit <code>src/App.svelte</code> and save to reload.</p>
    <a
      class="App-link"
      href="https://svelte.dev"
      target="_blank"
      rel="noopener noreferrer">
      {message}
    </a>
+  <Test />
  </header>
</div>

I get error:

[snowpack] ! updating dependencies...
[snowpack] ! installing dependencies…
[snowpack] Cannot find module '@components/Test.svelte'
Require stack:
- /home/jthegedus/projects/test/app/node_modules/snowpack/dist-node/index.js
- /home/jthegedus/projects/test/app/node_modules/snowpack/dist-node/index.bin.js
[snowpack] Install failed.

Not sure if I am doing something wrong here or if Snowpack resolution doesn't support this type of usage.

Relative importing works as expected (doing this 👇 ):

<script>
+  import Test from "./node_modules/@components/Test.svelte";

EDIT: I discovered HMR doesn't work on the relative import ./node_modules/@components/Test.svelte where it does on a component not under src/node_modules/*.

[jthegedus]

@Rich-Harris Not sure if svelte/kit addresses this or if your opinions on this have changed this particular usage, but here are some edge cases I have found.

[Rich-Harris]

SvelteKit currently uses aliases for this very reason but it would be cool if files like these could be resolved at runtime. No idea whether that's architecturally feasible

[drwpow]

We do try and discourage aliasing in general because it’s an additional level abstraction away from the code that runs in browser. A goal of Snowpack is to reduce the mental overhead that’s currently required in what you write vs what ships.

That said, we do support import aliases in your snowpack.config.js. This will work with both node modules as well as local files. But I’d recommend skipping the src/node_modules trickery if possible. Just because something is named node_modules doesn’t change how Snowpack treats it (other than your primary node_modules folder, that is).

Let me know if this solves your issue!

EDIT: I discovered HMR doesn't work on the relative import ./node_modules/@components/Test.svelte where it does on a component not under src/node_modules/*

For performance reasons, we do watch all mounted directories in your project for HMR, but we do not monitor node_modules. But if you need HMR for something in node_modules, we actually do offer HMR for locally-linked npm modules. But if we watched your entire node_modules directory it’d cause problems in certain project setups.

[jthegedus]

Thanks for the reply @drwpow but I was specifically wanting to avoid using aliases. Since SvelteKit is going to be based off of Snowpack and allow use of aliases I will fallback to that once it releases. The src/node_modules trickery is much more easy to use than aliasing in my experience.

[FredKSchott]

The magic of Snowpack is still in esinstall, which is our ability to upconvert packages from Common.js to ESM, saving them into a new ESM-only web_modules directory.

But esinstall is run at the top-level, so it doesn't support a node_modules directory nested in source like src/foo/node_modules/*. We'd like to avoid supporting this if at all possible, since it's a bit antithetical to how that works by creating a single, final install directory (ex: where does the nested dependency end up in the final web_modules dir? what if two nested names conflict? etc).

Since nested node_modules in source are usually just used for the convenience of a simpler import, our official project recommendation is to use Snowpack aliases to achieve this convenience instead.

[FredKSchott]

One thing that we'd like to explore more is the idea of treating some node_modules as source, for the purpose of giving npm link'd and/or monorepo linked packages a faster dev experience. Today, any dependency (even a linked one) has to go through that esinstall pipeline, which is slower than our instant dev pipeline for source code.

That solution could potentially solve for this as well, assuming this is something that we want to support.

But again, this is a workflow that we don't really want to support. Our official project stance is that mixing node_modules in with your source code is relying on a side-effect of Node.js loading behavior to achieve aliasing, and we provide first-class support for aliasing to use instead.

[johnpittman]

I am going through the same struggles where we have a react ui toolkit that imports .module.css files and snowpack is looking for a css.proxy.js at the location of the component being imported. this means i'll have to create a component wrapper for each component just to re-import the css into the snowpack project.