[BUG] Source maps not found in dev server for third party packages

[jbuckner]

Bug Report Quick Checklist

• [x] I am on the latest version of Snowpack & all plugins. (3.5.1)
• [x] I use package manager npm (Fill in: npm, yarn, pnpm, etc).
• [x] I run Snowpack on OS Mac (Fill in: Windows, Mac, Linux, etc).
• [x] I run Snowpack on Node.js v12+

Describe the bug

Enabling buildOptions.sourcemap: true causes the dev server to throw "file not found" errors for third party packages .map files. First-party modules don't have the problem

To Reproduce

We can't fix bugs that we can't see for ourselves. Issues often need to be closed if this section is skipped.

1. npx create-snowpack-app snowpack_sourcemap_test --template @snowpack/app-template-lit-element-typescript
2. cd snowpack_sourcemap_test
3. Edit snowpack.config.mjs, add buildOptions.sourcemap: true
4. Run npm run start
5. Look at console, see errors for http://localhost:8080/_snowpack/pkg/lit-html.js.map et al.

Expected behavior

No source map errors during development.

Anything else?

The source maps are properly being generated when doing npm run build, just not during dev.

[franktopel]

I can confirm this is still an issue as of 3.6.2, using the blank template along with Node 14.17.1 and npm 7.19.0, on MacOS 11.4.

I'm getting [404] Not Found (/_snowpack/pkg/custom-elements.js.map) when running the development server:

Chrome console confirms this:

This is my snowpack.config.mjs:

/** @type {import("snowpack").SnowpackUserConfig } */
export default {
  mount: {
    public: { url: '/', static: true },
    src: { url: '/dist' },
  },
  plugins: [
    [
      '@snowpack/plugin-babel',
      {
        transformOptions: {
          sourceMaps: "inline"
        },
      }
    ],
    [
      '@snowpack/plugin-webpack',
      {
        sourceMap: true,
        outputPattern: { html: './build/' },
      },
    ],
  ],
  routes: [
    /* Enable an SPA Fallback in development: */
    // {"match": "routes", "src": ".*", "dest": "/index.html"},
  ],
  optimize: {
    /* Example: Bundle your final build: */
    "bundle": true,
  },
  packageOptions: {
    /* ... */
  },
  devOptions: {
    /* ... */
    "open": "chrome",
  },
  buildOptions: {
    /* ... */
    sourcemap: true,
  },
};

and this is my index.js:

import '@ungap/custom-elements';

Imo snowpack shouldn't try to generate or load sourcemaps for any third party packages in the first place.

As it is now, this leaves snowpack in an unusable state, as it keeps reporting these errors in every watch step. Imagine having 50+ external dependencies and snowpack dev reporting this in the console for each of those 50 packages every time you make a change.

Edit: Diving deeper into the matter, I found that by the looks of it only certain external dependencies cause this problem.

E.g. importing jquery doesn't cause the same error, while @webcomponents/webcomponentsjs does also result in the same error.

[omochi]

I have same issue. I am using chakra-ui. Its prebuilt javascript which I hosted already has relative path to source map.

This is screenshot for button.js.

But snowpack dev server doesn't host button.js.map which exists at same directory with button.js.

[melink14]

I was running into this problem with web-test-runner coverage mode looking up these broken sourcemaps and causing logspam.

The way the dev server works is by building the files in memory when they get requested so this problem means the internal mapping isn't working for some reason.

The problem with external deps was introduced with a refactor that happened earlier this year: https://github.com/snowpackjs/snowpack/blob/91cd7dd1c9239542842814f99ad4e40cf94d18ba/snowpack/src/commands/dev.ts#L510-L515

You can see here that for some reason instead of properly serving a sourcemap the code removes the .map suffix and attempts to serve the file itself. (Which is not valid sourcemap json...)

I didn't debug deeply why those files sometimes also 404 (since 404s are ignored during coverage) but it's probably a proximate cause.

A workaround/fix is to realize that sourcemap: true is not a valid option and instead you should use sourcemap: inline which as far as I can tell works correctly. I noticed in intellisense that false and 'inline' are the only two accepted value for that option even though the online docs just say it's a boolean flag...

One warning: even though the sourcemap option changes these external packages, the cache is not invalidated and thus you won't see any change if you don't also run snowpack build --reload which clears the cache. I plan to open another issue for that later.

[melink14]

It seems like when the lateset sourcemap changes were made it was expected that snowpack would treat true as inline which is what happens during build but for local install of packages this wasn't changed: https://github.com/snowpackjs/snowpack/blob/96ecac36439034d61d56ba2c18f004567a6cea8b/snowpack/src/sources/local.ts#L575

If I change that line to end with && 'inline' then things work okay (though it causes some of my tests to fail...). I can also change it to false which causes no harm as far as I can tell. (though there was at least one person trying to get sourcemaps to work there: https://github.com/snowpackjs/snowpack/discussions/3280)

For consistency, it seems that we should use && 'inline' everywhere or throw an error if people pass true as an option.

I think long term though there's no reason why URL based sourcemaps shouldn't work if we fix the issues in dev.ts I mentioned above.