Simplify. cleanup, enhance snowpack internals

Changes

snowpack dev - 500 lines of code refactored away, old branching code paths now unified into a single pipeline.
snowpack build - ~350 lines of code refactored away, including a full rewrite of the build pipeline to reuse the dev server internally for file builds.
NEW: npm packages are now built using the Snowpack build pipeline - no special rollup plugins needed to build non-JS dependencies. The isPackage flag had been added to the plugin load() hook so that plugins can customize their behavior.
NEW: Svelte package SSR support - Svelte packages can ship ".svelte" files in their package distribution, which means that packages are expected to build differently in SSR vs. non-SSR mode. Snowpack now supports this.
NEW: Individual package builds - building on our work in esinstall, each npm package is now built & served individually during development. This means that a change to a package (ex: on npm/yarn update) no longer forces the rebuild of your entire dependency tree. This results in a slower first start, but then almost zero cold starts / rebuilds in the future.
(As a part of this work, we experimented with esbuild for package installation. Unfortunately, we found that esbuild support is not yet up to par with all of the features of esinstall and failed to build trickier packages. We'll keep an eye on this for a future, possibly v4.0 release. Now that we build packages individually, we can also experiment with passing most packages through esbuild & leaving esinstall around for legacy, trickier packages.)
NEW: Improved workspace/linked package support. We now treat npm linked packages as source files by default, giving workspaces instant rebuilds and full HMR support, out of the box.
NEW: Improved output defaults for build & programatic usage  (no browser open by default, streaming logs instead of default, etc)

Issues resolved

https://github.com/snowpackjs/snowpack/discussions/1808
https://github.com/TheComputerM/svelte-materialify/issues/132
Probably more! If you are having trouble with Snowpack's latest version, I'd recommend checking out this version first and seeing if your issue is resolved.

Testing

Tests updated and added.

Docs

No docs updates needed. Interface is essentially identical. The release notes will just need some tips in case anyone gets stuck upgrading.

Hey, as response to your message here I did a quick test. I created a NPM workspace with the following structure:
/monorepo
  /packages
    /app
    /lib
  package.json

The workspace package.json has nothing special:
{
  "name": "react-monorepo",
  "private": true,
  "version": "1.0.0",
  "workspaces": [
    "./packages/*"
  ]
}

The app and the lib are both created from @snowpack/app-template-preact-typescript. I gived both a name in the package.json, updated all dependencies, installed snowpack@next and referenced lib ind app. Then I created a simple CSS file in lib and imported it in app. After running npm install and starting the app, I get the following error:
[snowpack] (node:6372) UnhandledPromiseRejectionWarning: TypeError: fsevents.watch is not a function
    at createFSEventsInstance ([...removed]/react-monorepo/node_modules/snowpack/lib/index.js:127128:25)
    at setFSEventsListener ([...removed]/react-monorepo/node_modules/snowpack/lib/index.js:127183:16)
    at FsEventsHandler._watchWithFsEvents ([...removed]/react-monorepo/node_modules/snowpack/lib/index.js:127385:18)
    at FsEventsHandler.initWatch ([...removed]/react-monorepo/node_modules/snowpack/lib/index.js:127461:23)
    at FsEventsHandler._addToFsEvents ([...removed]/react-monorepo/node_modules/snowpack/lib/index.js:127550:12)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
(Use `node --trace-warnings ...` to show where the warning was created)
[snowpack] (node:6372) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
[snowpack] (node:6372) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
[snowpack] (node:6372) UnhandledPromiseRejectionWarning: TypeError: fsevents.watch is not a function
    at createFSEventsInstance ([...removed]/react-monorepo/node_modules/snowpack/lib/index.js:127128:25)
    at setFSEventsListener ([...removed]/react-monorepo/node_modules/snowpack/lib/index.js:127183:16)
    at FsEventsHandler._watchWithFsEvents ([...removed]/react-monorepo/node_modules/snowpack/lib/index.js:127385:18)
    at FsEventsHandler.initWatch ([...removed]/react-monorepo/node_modules/snowpack/lib/index.js:127461:23)
    at FsEventsHandler._addToFsEvents ([...removed]/react-monorepo/node_modules/snowpack/lib/index.js:127550:12)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
[snowpack] (node:6372) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)

The app starts but any changes to the CSS file are not tracked.
I hope it helps.

@FredKSchott
When I try to use snowpack’s new monorepo features, I get the following message.

[snowpack] Locally linked package detected outside of project root.
Locally linked/symlinked packages are treated as static by default, and will not be
rebuilt until its "package.json" version changes. To enable local updates for this
package, set your project root to match your monorepo/workspace root directory.

Is there a dummy-proof explanation about what I’m supposed to do here? Not sure where I’m setting a “project root” and I can’t find the code which emits this warning.
Realized that it’s a configuration setting in snowpack.config.js. I thought it was something to do with monorepos and package.json. Maybe that could be clarified. Thanks for this feature!

It seems like setting the root outside the expected root has some unusual effects with regard to plugins. I am now getting the following build error.

[snowpack] Set up complete!
[snowpack] watching for file changes...
[snowpack] Build Result Error: There was a problem with a file build result.
[snowpack] SyntaxError<EMAIL_ADDRESS>Unexpected token (1:12)

My snowpack.config.js is as follows:
module.exports = {
  root: "../..",
  mount: {
    public: "/",
    src: "/js",
  },
  plugins: [
    "@snowpack/plugin-dotenv",
    "@snowpack/plugin-babel",
    "@snowpack/plugin-typescript",
  ],
  packageOptions: {
    installTypes: true,
  },
  devOptions: {
    "open": "none",
    "hmrErrorOverlay": false,
  },
};

Oh nice! what did you do to solve / did it work? Agreed, that message could make it more clear how to resolve.

@FredKSchott wasn’t able to get it working due to the issue above and am backing out for now. Back to snowpack dev --reload 😤 Let me know if you want me to file a separate issue.

It looks like Babel isn't picking up your config now, probably due to this line in the plugin:
cwd: snowpackConfig.root || process.cwd()

I wonder if it makes sense to add a new workspaceRoot for this instead, and not force people to mess with their own config.root. I do still like the idea of your "Snowpack Root" being the root of the application that you're running.

Installed via snowpack@next, currently version is 3.1.0-pre.2
Having a hard time running:

without any path reference:

config:

module.exports = {
  mount: {
    src: { url: '/dist' },
    public: { url: '/', static: true, resolve: false },
  },
  devOptions: {
    port: 3003,
  },

output error: [snowpack] Package "@myorg/api/Client" not found. Have you installed it?

with alias set:

config:

module.exports = {
  mount: {
    src: { url: '/dist' },
    public: { url: '/', static: true, resolve: false },
  },
  devOptions: {
    port: 3003,
  },
  alias: {
    '@myorg': '../',
  },

output error: [404] Not Found (/_snowpack/api/Client.js):  ✘ /_snowpack/api/Client.js

I'm not sure how I must be setting snowpack to pick my workspaces.

It looks like Babel isn't picking up your config now, probably due to this line in the plugin:

I tried moving my .babelrc file to the root but this didn’t seem to do have any effect. Nor did explicitly referencing the config via a command-line flag.

I wonder if it makes sense to add a new snowpack.workspaceRoot for this instead, and not force people to mess with their own config.root. I do still like the idea of your "Snowpack Root" being the root of the application that you're running.

I think if plugins have implicit assumptions about the configured root, then having a separate concept of a workspaceRoot would be prudent.

We could even auto-detect this by traveling up from your config.root to the first directory with a package.json that contains a workspaces property.

Less configuration is always nice!

@brainkim workspaceRoot added in dbc760a, and comment updated for clarity

@Negan1911 try removing the alias (no longer needed for workspaces) and running the latest 3.1.0-pre.3 release. If that doesn't work, I'd be curious why it can't find @myorg/api/Client in your workspace. Does that path exist in your workspace's node_modules/@myorg/api/Client? Is Client a directory, or a file? If its a file, does adding a missing file extension help at all?

@FredKSchott just tested with 3.1.0-pre.3 removing the alias, I can confirm that under the root node_modules I can see @myorg/api/Client.tsx file,  when running, I got this output:
Package "@myorg/api/Client" not found. Have you installed it?

I also tried ruling out a typescript issue by installing @snowpack/plugin-typescript with no luck

@Negan1911 okay good, then I think we just need to add support for missing file extensions in packages, which we already have in normal Snowpack. Thanks for the help testing!

@FredKSchott Thanks! It works flawlessly! A real game-changer for writing quick demos for libraries!

I just tested with 3.1.0-pre.4 on Node v15.4.0 and I can't run snowpack build nor snowpack build --watch anymore.
Here's the output:
$ /shared/httpd/snowpack/node_modules/.bin/snowpack build --watch
[snowpack] watching for file changes...
[snowpack] ! building files...
/shared/httpd/snowpack/node_modules/snowpack/lib/index.js:127161
  const stop = fsevents.watch(path, callback);
                        ^

TypeError: fsevents.watch is not a function
    at createFSEventsInstance (/shared/httpd/snowpack/node_modules/snowpack/lib/index.js:127161:25)
    at setFSEventsListener (/shared/httpd/snowpack/node_modules/snowpack/lib/index.js:127216:16)
    at FsEventsHandler._watchWithFsEvents (/shared/httpd/snowpack/node_modules/snowpack/lib/index.js:127418:18)
    at FsEventsHandler.initWatch (/shared/httpd/snowpack/node_modules/snowpack/lib/index.js:127494:23)
    at FsEventsHandler._addToFsEvents (/shared/httpd/snowpack/node_modules/snowpack/lib/index.js:127583:12)
    at processTicksAndRejections (node:internal/process/task_queues:93:5)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

I'm continuing to troubleshooting on my side to see if it's my setup.

From some quick googling, it looks like that's a Node v10 issue? If you upgrade to Node v12, does it go away? Or, are you already on Node v12+?

@Negan1911 support for file extension lookups added in latest commit! test added as well to confirm. Can you test the latest next release again in your project?

I tried running 3.1.0-pre.5 against our codebase and I encountered an error during dependency install that was not happening earlier. The problem is with a JSON import in @formatjs/ecma402-abstract, which is a dependency of the @formatjs/intl-numberformat polyfill library:
[snowpack] ⦿ @formatjs/ecma402-abstract
[snowpack] Package(s) failed to build: Error loading<EMAIL_ADDRESS>plugin load hook should return a string, a { code, map } object, or nothing/null
error Command failed with exit code 1.

I'm not sure what the problem is with digit-mapping.json. If I cat the file it's there, and it looks like a valid JSON file to me.
Anyway, it's reproducible. I've created a repro based on app-template-minimal here: https://github.com/jonrimmer/snowpack-formatjs-error.

@FredKSchott so, looks like it's working quite better, but there's one package which fails and I'm not sure why...
@myorg/Layout has an entry point (index.tsx) which is this file:
export * from './Layout'

If I ran that, I receive: [snowpack] [404] Not Found (/_snowpack/pkg/Layout)
On the other side, if I replace the export *  with the actual code which is exporting (and run snowpack dev --reload) it seem at first glance like it worked, but turns out that is just forwarding uncompiled typescript code to the UI as you can see on this screenshot:

The file which is requering this is http://localhost:3003/_snowpack/pkg/tsx

Thanks for looking into the static content issue I reported in this change! It seems like there are still some issues though:

If I set buildOptions.baseUrl to http://localhost:8000 and import a logo.svg, logo.svg.proxy.js contains
export default "http:/localhost:8000/logo.svg"; - one of the forward slashes in the http:// got deleted! I've seen this happen before if you try to throw a URL through Node's path tools, so it might be something to do with that.
The dev server still doesn't honour buildOptions.baseUrl at all - it would be nice if it could, since it's a requirement for running microfrontend apps locally.

I've tested this against the minimal repro repo I made, using Snowpack 3.1.0-pre.5.

@FredKSchott -- this new version is almost fully working in a TypeScript + NPM workspaces monorepo. Here's what's missing (quite possibly due to misconfiguration):

Snowpack doesn't pick up changes in the common tree unless I run a separate tsc -b -w (it does correctly rebuild on changes in the client tree)
Sourcemaps error out

@jonrimmer fixed! Thanks for catching that, seemed to be an issue with Snowpack build plugins that returned Buffers instead of strings.
@Sorixelle baseUrl issue fixed! The "supporting baseUrl in dev" issue isn't related to this PR, but would love to discuss post merge in a seperate PR.
@Negan1911 okay interesting. Can you try re-running with snowpack dev --reload? When a symIinked package is used successfully, it should be loaded from /_snowpack/link/* instead of /_snowpack/pkg/*. It looks like your package is being loaded from /pkg which means its running through our esinstall package bundler, and won't get the full workspace experience. See screenshot:

@FredKSchott indeed I'm running it with --reload and having the same issue.

@Negan1911 okay, I'm not sure what that could be then. My best guess is that it isn't being detected as a workspace'd package for some reason, but the fact that its serving TypeScript right out of the pkg directory doesn't make much sense either. If there's any chance that you could reproduce in a repo that I could check out locally, that would be amazing!
@soncodi This feels like something that we may want to solve with some documentation. Even when a package is in your workspace, we'll still resolve it based on normal package.json entrypoints. So we see your common package's "main" entrypoint and resolve to that, even though that points to a file that needs to be built seperately.
Instead, we should resolve to a package "source" entrypoint automatically. It would be up to you to add that to your package.json, but then we'd know where to resolve it to by default.

@soncodi  added support to automatically read from the package.json snowpack:source entrypoint. This entrypoint is only meant for workspace packages, and shouldn't be published to npm (will add docs).
"main": "index.cjs", // or whatever you compile to
"snowpack:source": "index.tsx"

To me, the ideal behavior is what tsc -b does for TS project references: trigger a rebuild/hmr on client when its dependency common changes. Is that not possible with Snowpack?

@FredKSchott yeah, there's no alias neither on tsonfig nor on snowpack config... strange :(

@soncodi yup, that is possible, but Snowpack just needs to know that import "pkg" means pkg/index.ts and not a compiled pkg/index.cjs. Right now, the package.json in your test repo only points to a compiled "main" entrypoint.
If these packages (like "common") won't be published, you can also just point "main" to the source file directly.

@FredKSchott: pointing "main" to the .ts files fixed the issue; client now reloads on changes to common.
But, I'm still getting this error on snowpack build --verbose:
[snowpack] Build Result Error: There was a problem with a file build result.
[snowpack] /snowpack-test/client/src/modules.d.ts - Requested content ".js" but built
[snowpack] Error: /snowpack-test/client/src/modules.d.ts - Requested content ".js" but built
    at FileBuilder.verifyRequestFromBuild (/snowpack-test/node_modules/snowpack/lib/index.js:112711:19)
    at FileBuilder.getResult (/snowpack-test/node_modules/snowpack/lib/index.js:112917:42)
    at Object.loadUrl (/snowpack-test/node_modules/snowpack/lib/index.js:129107:51)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async flushFileQueue (/snowpack-test/node_modules/snowpack/lib/index.js:129539:28)
    at async build (/snowpack-test/node_modules/snowpack/lib/index.js:129561:5)
    at async Object.command (/snowpack-test/node_modules/snowpack/lib/index.js:129633:9)
    at async cli (/snowpack-test/node_modules/snowpack/lib/index.js:129939:9)

Awesome, looks like it's sorted on prod builds now! We can talk more about a dev server implementation on #2407, where I was taking a jab at solving the issue. Thanks for the amazing work! :rocket:

Thanks @FredKSchott! pre.6 fixed the problem with the formatjs package. Unfortunately, we've then encountered another one, with react-spring v9.rc3, due to it relying, through a chain of dependencies, on @alloc/types:
[snowpack] ⦿ @alloc/types
[snowpack] Build Result Error: There was a problem with a file build result.
[snowpack] Error: Package(s) failed to build: No ESM dependencies found!
  At least one dependency must have an ESM "module" entrypoint. You can find modern, web-ready packages at https://www.skypack.dev
    at /Users/jonathanrimmer/GitHub/snowpack-react-spring-error/node_modules/snowpack/lib/index.js:53753:15
    at async Object.installPackages (/Users/jonathanrimmer/GitHub/snowpack-react-spring-error/node_modules/snowpack/lib/index.js:53707:25)
    at async /Users/jonathanrimmer/GitHub/snowpack-react-spring-error/node_modules/snowpack/lib/index.js:54055:64
    at async run (/Users/jonathanrimmer/GitHub/snowpack-react-spring-error/node_modules/snowpack/lib/index.js:46925:29)
[snowpack] Error: Package(s) failed to build: No ESM dependencies found!
  At least one dependency must have an ESM "module" entrypoint. You can find modern, web-ready packages at https://www.skypack.dev

I think the problem here is that @alloc/types is a TypeScript utility library that doesn't define a main entrypoint, just types. I guess there might be a few such libraries out there. Note that its parent dependency @react-spring/shared, doesn't actually import anything from @alloc/types, it's just listed a dependency. So, I guess technically this is react-spring bug, as @alloc/types should only be a dev dependency, but maybe Snowpack can still handle this somehow? Perhaps by assuming that any package with a types/typings field but not main/module is a types library and ignoring it?
Repro here: https://github.com/jonrimmer/snowpack-react-spring-error

[snowpack] Build Result Error: There was a problem with a file build result.
[snowpack] /snowpack-test/client/src/modules.d.ts - Requested content ".js" but built
[snowpack] Error: /snowpack-test/client/src/modules.d.ts - Requested content ".js" but built

Same thing, it seems to be working if file exports something (generates js) but if file has not output (contains only types) - snowpack bails out with this error

@FredKSchott I just isolated the issue and uploaded it into a repo: https://github.com/Negan1911/snowpack-monorepo
See the attached readme because I think that snowpack is failing to detect imports from a parent folder and thinks that's a module (I attached a patch to solve the issue so you can see what's actually causing it)

@Coobaha: good find; snowpack build succeeds if I remove the .d.ts files, but that's not an option for real projects.

@FredKSchott Thanks for the fsevents fix.
I've updated to 3.1.0-pre.5 and am trying out snowpack build --watch with HMR on a minimal setup and it doesn't seem to work like it sorta did in 3.0.13.
A couple of things I've noticed between this version and the stable version:

Running snowpack build--watch with HMR doesn't print the WebSocket URL in the console anymore
If devOptions.hmrPort is unset, the port seems to be random instead of defaulting to 12321
Using 12321 as the port and using window.HMR_WEBSOCKET_URL ="ws://localhost:12321"; in my main script works on 3.0.13 but gives me an ERR_CONNECTION_REFUSED in the console with 3.1.0-pre.5.

I'm not sure what is intended and what is not, but these are my observations so far. Thanks for all your work.

Snowpack 3.0.12 didn't properly handle empty files - either because the file itself was empty or because it compiled to empty output such as a typescript file that only exported types - Snowpack threw a 404.
I tried out 3.1.0-pre.6 to see if it got any better but it behaviour seems to have gotten more noisy and worse. It now throws a 500 error when trying to load an empty file.
To reproduce

Create a new project with npx create-snowpack-app snowpack-test --template @snowpack/app-template-preact-typescript

Update the snowpack version in package.json to 3.1.0-pre.6

Create a new file at src/types.ts with the content export type AType = 'hello'; (compiling this content will result in an empty file, you could also leave this file totally empty or containing just a comment)

Edit src/App.tsx: Adding the following:
import * as exportsFromTypes from './types';

console.log(exportsFromTypes);

The console.log is present so that the import is used and thus is not elided

Load the page in the snowpack dev server. See that attempting to load the dist/types.js file fails with the following error message:

[snowpack] [500] /dist/types.js
[snowpack] Build Result Error: There was a problem with a file build result.
Error: /Users/ben/projects/snowpack-test/src/types.ts - Requested content ".js" but built
    at FileBuilder.verifyRequestFromBuild (/Users/ben/projects/snowpack-test/node_modules/snowpack/lib/index.js:112711:19)
    at FileBuilder.getResult (/Users/ben/projects/snowpack-test/node_modules/snowpack/lib/index.js:112917:42)
    at loadUrl (/Users/ben/projects/snowpack-test/node_modules/snowpack/lib/index.js:129107:51)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async handleRequest (/Users/ben/projects/snowpack-test/node_modules/snowpack/lib/index.js:129177:28)

Hi, thanks for the great work and I hope to see this PR in the future.
At the moment I can't get it to run. Please see my setup here. When I try to import a typescript file from the lib package, it can't be found. And when I try to import a simple JS file from the 'simple' package, I get it running, but no changes are tracked at all.
Node: 14.16.0
Yarn:  1.22.10
System: Linux

@FredKSchott could you release the modified plugins to npm as well? i would like to test if this completly solves  TheComputerM/svelte-materialify#132

@betaboon ah, that's a great call. I'll publish a @snowpack/plugin-svelte@next release with the next snowpack@next release

@krevativ when @local/simple is installed, do you see this message?
[snowpack] Locally linked package detected outside of project root.
If you are working in a workspace/monorepo, set your snowpack.config.js "workspaceRoot"
to the workspace directory to take advantage of fast HMR updates for linked packages.
Otherwise, this package will be cached until its package.json "version" changes.

If I set this in your config file, it seems to work!
  workspaceRoot: '../../',

We could make this warning noisier, but I'm not sure if I love that either. Maybe we show it on every run, but then give you an option to set workspaceRoot: null to silence the warning.
Also, Earlier in this PR someone had suggested setting this automatically (look for the first parent directory that includes a package.json, with a workspaces property.) We may want to prioritize that work as a part of this PR as well.
Anyway, setting workspaceRoot seemed to fix both issues for me in your test repo!
// once workspaceRoot was set, this worked as well!
import Button from '@local/lib/src/Button';

@soncodi @Coobaha fixed the d.ts issue!
@jonrimmer great catch, fixed an issue where types only packages were failing, even if they had an empty "index.js" file.
@PaulMorel reverted some of those HMR changes back to previous behavior (defaulting to 12321, logging the port, etc). I couldn't reproduce the connection failure error that you mentioned. Maybe try again on the latest next release and then share a repro if you can still reproduce?

@FredKSchott I had a go with snowpack@next and a very simple monorepo set up, similar to @krevativ . Using workspaceRoot as you described I can see the package being added to the link directory however I don't get hot reloading.
I can only see changes to packages/engine/index.js when stopping and starting the server.
yarn -v
1.22.4
node -v
v14.15.5

@alex-page: you can add snowpack:source to your package.json to point snowpack to the .ts files (per https://github.com/snowpackjs/snowpack/pull/2707#issuecomment-785557143). See https://github.com/soncodi/snowpack-ts-monorepo for a working repo.

I still have the same issue. Just pushed up the snowpack:source to that test repo.

@alex-page nope that's a good catch, introduced a bug in pre.7 bug with file watching, fixed in 5de006c6. Tested your test repo as working with that fix. Thanks for catching!

@FredKSchott my bad sorry, I didn't saw the message because the terminal is cleared at the end. Thanks for the quick reply, it helped indeed.
I think setting it automatically would be a nice idea. I did already something similar with webpack and it worked perfectly.
Maybe it would help to show the message after the server starts at the end again?

@FredKSchott I can confirm my empty file loading issue is fixed. Thanks!
I've found another regression from snowpack 3.0.x for you:
In app code importing a json file from a package works great. However if you try to import a package that then imports a json file from another package then it throws an error. It looks like compiled package code tries to load the JSON file directly (e.g<EMAIL_ADDRESS>instead of using a proxy  (e.g. http://localhost:8080/_snowpack/pkg/@shopify.polaris-tokens.dist-modern.theme.base.v2.20.0.json.proxy.js).
I've created a reproduction repo at https://github.com/BPScott/snowpack-test-polaris. Here's the specific commit that demonstrates how you'd need to modify a base snowpack react+typescript template to demonstrate the behaviour.
In this particular example @shopify/polaris contains an import: import DefaultThemeColors from<EMAIL_ADDRESS>
App code  imports@shopify/polaris and which is loads data from<EMAIL_ADDRESS>That compiled js contains import DefaultThemeColors$1 from<EMAIL_ADDRESS>I would expect that to be import DefaultThemeColors$1 from<EMAIL_ADDRESS>

@BPScott ah good catch. Just pushed up a fix. I can get your test repo running now with 1 line of config added:
  packageOptions: {
+    namedExports: ["@shopify/polaris-tokens"]
  },

It looks like this package is failing to pass our automatic CJS named import scanner (the same scanner that Node.js uses for ESM<>CJS interop) so we need to add it here explicitly. I also cleaned up this section of the docs site to help others.

@krevativ added a single message now for every run, with the ability to silence it with workspaceRoot: false! Also pushed a big output cleanup last night that no longer needs to take over your entire console anymore.
Publishing a new next release now, and I think this PR is getting close to merge 🎉  A huge thanks to everyone who was able to help test this rewrite and catch bugs before launch! Please keep posting any issues that you encounter

I was trying to use SvelteKit with this branch and found that Snowpack breaks if there are any .map files (which it does).
Snowpack assumes that if you're asking for a .map file it's one generated by snowpack, but it breaks if you're asking for an existing .map file.
I have a functioning fix at Liamolucko@2a516bf2e5007d08e8f570f1d5cab0a014297ca5, but it's probably not the best way to go about it.

@Liamolucko ah nice, I was just about to try out SvelteKit before merging. Pushing a fix for this now

@FredKSchott In a simple workspaces repo, when both client and common packages import mobx, the app breaks trying to resolve http://localhost:8081/_snowpack/_snowpack/pkg/mobx.v6.1.7.js.
It works if either package imports mobx but not both. Which package.json(s) should have the mobx dep?

Coming over from
https://github.com/snowpackjs/snowpack/issues/2759#issuecomment-787529089
The next branch is causing more unexplained errors than the previous version.

It looks like this package ([@shopify/polaris-tokens]) is failing to pass our automatic CJS named import scanner (the same scanner that Node.js uses for ESM<>CJS interop) so we need to add it here explicitly. I also cleaned up this section of the docs site to help others.

Thanks for that context! It looks like there's a few things I need to tidy up in that package. Ideally I can expose ESM but as a band-aid I can change the main file so that instead of pointing to https://unpkg.com/browse/<EMAIL_ADDRESS>it goes direct to https://unpkg.com/browse/<EMAIL_ADDRESS>should be enough to keep rollup happy per compat tables when writing import {durationBase} from '@shopify/polaris-tokens';. (Thought I ideally I should use a named exports rather than exporting an object).
When applying that fix mentioned above and  not adding any namedExports config I still get errors when importing content from the dist-modern folder - The requested module<EMAIL_ADDRESS>does not provide an export named 'colorFactory' when requesting in the form import {colorFactory} from '@shopify/polaris-tokens/dist-modern';. Which is somewhat suprising to me as that is cjs produced by the typescript compiler - I would have expected that to output cjs that other tools could interop with. It's not the end of the world, and the ideal fix is "just ship ESM"  but I thought it might be of interest.

@soncodi - if you remove './common/src': { url: '/dist/@soncodi/common' }, from your config it works. We should add a warning if we find a symlinked package conflicts with something that you've mounted.
@BPScott - you're right, I'm surprised by that result. Opened an issue here to track: https://github.com/guybedford/cjs-module-lexer/issues/37
@volkanunsal - you can see instructions in the thread above to add uuid under namedExports in your config to fix this sort of issue (also, the latest uuid package ships as ESM). If this kind of issue will become more common in larger projects, we can look to automate this or at least point you towards the fix in our error log.

Another SvelteKit problem: @snowpack/plugin-svelte isn't generating .css files, only .css.proxy.js files.

@Liamolucko thanks for the heads up, can you share some steps to reproduce / is that in one of the SvelteKit starter apps? I can't reproduce that in our own app-template-svelte template

It reproduces with app-template-svelte on my end:

package.json:
{
  "scripts": {
    "start": "snowpack dev",
    "build": "snowpack build",
    "test": "web-test-runner \"src/**/*.test.js\""
  },
  "dependencies": {
    "svelte": "^3.24.0"
  },
  "devDependencies": {
    "@snowpack/plugin-dotenv": "^2.0.5",
    "@snowpack/plugin-svelte": "^3.1.0-pre.7",
    "@testing-library/svelte": "^3.0.0",
    "@web/test-runner": "^0.12.0",
    "chai": "^4.2.0",
    "snowpack": "^3.1.0-pre.10"
  }
}

The Svelte project compiles, but the HMR does not work, only the "File changed:" log is updated.

@Filyus the svelte file compiles for me for HMR with snowpack dev in create-snowpack-app/app-template-svelte. Would love steps to reproduce.
@Liamolucko thanks for the repro, fixed!

I'm running into [404] Not Found (/_snowpack/link/packages/component/src/Component.svelte.css.proxy.js).
I'm trying to use a pnpm-workspaces based monorepo.
verbose-log is here: https://gist.github.com/betaboon/a16211c93baed1f5189172e504503a97
repro is here: https://github.com/betaboon/snowpack-svelte-monorepo-repro
additionaly i noticed i had to add svelte-hmr explicitly to each package, dont know why.

Similarly to @betaboon, I am getting a Error: Not Found for .css.proxy.js files when building.  I am using yarn workspaces, and not svelte.  I just wanted to speak up since it doesn't seem like it's a svelte-specific issue.

Similarly to @betaboon and @IanVS I have this issue too.
And I don't know if it relates to this PR because it also doesn't work on the stable version, so sorry if not. But I don't get any sourcemaps in typescript (I saw that this seems to be a known issue). And I have a problem with aliases too. When I, for example, try to use preact with preact/compat mode, it only works when I specify an absolute path. So instead of alias: { react: "preact/compat" } I need to specify something like alias { react: "../../node_modules/preact/compat/dist/compat.js" }

@IanVS @betaboon thanks for catching, I can reproduce as well. Adding this to our test case

@FredKSchott i can confirm that it is fixed with 3.1.0-pre.11

@FredKSchott We're still having problems using react-spring.
https://github.com/jonrimmer/snowpack-spring-problem-2
Unhandled Runtime Error
Uncaught SyntaxError: The requested module<EMAIL_ADDRESS>does not provide an export named 'FrameLoop

Source
<EMAIL_ADDRESS>[:4:10]
SyntaxError: The requested module<EMAIL_ADDRESS>does not provide an export named 'FrameLoop'

When I look at the cached code in node_modules/.cache/snowpack/development/@react-spring/shared<EMAIL_ADDRESS>some of the code looks very strange:
export { FrameLoop, createInterpolator, defineHidden, each, flush, is, isAnimatedString, isEqual, noop, toArray, useForceUpdate, useOnce, usePrev } from '@alloc/types';

None of these things, FrameLoop etc, are defined/exported in @alloc/types, even as TypeScript definitions. They're part of the @react-spring/shared package itself, so I have no idea how they ended up in an export from @alloc/types statement. There is no equivalent export in the sources for this package: https://github.com/pmndrs/react-spring/tree/v9/packages/shared/src

@Filyus the svelte file compiles for me for HMR with snowpack dev in create-snowpack-app/app-template-svelte. Would love steps to reproduce.
@Liamolucko thanks for the repro, fixed!

npx create-snowpack-app svelte-snowpack --template @snowpack/app-template-svelte
npm i -D snowpack@next @snowpack/plugin-svelte@next
npm run start

Try to change src/App.svelte, the content of the webpage will not change in live.

Thanks!
We have been looking forward to using this feature.
However, we experience the following issue:

In our monorepo, we have modules that import package.json
I understand that we can not import it unless placed in src/ so we created clones named src/package.clone.json and, and then we use import {name, dependencies} from "./src/package.clone.json"; in our index.js (outside or src)
The snowpack build now fails with

[17:22:11] [snowpack] ! building files...
[17:22:12] [snowpack] Not Found (/_snowpack/link/modules/core/core-web/src/package.clone.json.proxy.js)
[17:22:12] [snowpack] Error: Not Found (/_snowpack/link/modules/core/core-web/src/package.clone.json.proxy.js)
    at Object.loadUrl (.../node_modules/snowpack/lib/index.js:130468:23)
    at async flushFileQueue (.../node_modules/snowpack/lib/index.js:130931:28)

Somehow it appears to me that JSON files placed in _snowpack/link/modules do not get the .proxy.js suffix - is that possible?

@Filyus the svelte file compiles for me for HMR with snowpack dev in create-snowpack-app/app-template-svelte. Would love steps to reproduce.

npx create-snowpack-app svelte-snowpack --template @snowpack/app-template-svelte
cd svelte-snowpack
npm i -D snowpack@next @snowpack/plugin-svelte@next
npm run start

Try to edit src/App.svelte, the content of the webpage will not change in live.

i cannot reproduce that behavior, following your steps it works fine for me

@brainkim Try to start a second instance, it will ask you to use port 8081, answer "Y" and after that HMR does not work.

@brainkim Try to start a second instance, it will ask you to use port 8081, answer "Y" and after that HMR does not work.
I used a hack to replace index.html, and that was the root cause of my problem:
  mount: {
    public_snowpack: {url: '/', static: true, resolve: false},
    public: {url: '/', static: true, resolve: false},
    src: {url: '/dist'},
  },

@Filyus are you saying your problem went away?
even with two instances running i cannot reproduce the issue you described.
https://user-images.githubusercontent.com/7346933/109883518-d3bafa00-7c7b-11eb-8e8b-334adcc658da.mp4

@brainkim  Try to run from different folders. The second instance does not updates the site, but the first one updates both at the same time.
Yes, this problem has disappeared, but one more remains:
try npm i swiper
and add it to App.svelte:
<script>
  import { Swiper } from "swiper/svelte";
</script>
<Swiper/>

this will produce:
Uncaught TypeError: Swiper is not a constructor

@brainkim Try to run from different folders. The second instance does not updates the site, but the first one updates both at the same time.

thanks for clearing that up. i can reproduce this behavior.
btw: i think you are highlighting the wrong person ;)

Got it! I know where this is happening, fixing now!

There two problems related to Swiper:

Snowpack chooses cjs version on build:

//node_modules\swiper\svelte\package.json
{
  "name": "swiper/svelte",
  "private": true,
  "main": "../swiper-svelte.cjs.js",
  "jsnext:main": "../swiper-svelte.esm.js",
  "module": "../swiper-svelte.esm.js",
  "sideEffects": false
}

Swiper does not find __esModule and adds ".default" property a second time:

//node_modules\swiper\cjs\svelte\swiper.js
exports.default = Swiper;

//node_modules\swiper\swiper-svelte.cjs.js
var _swiper = _interopRequireDefault(require("./cjs/svelte/swiper"));
function _interopRequireDefault(obj) {
  return obj && obj.__esModule ? obj : {
    default: obj
  };
}

I've found an issue with relative paths imports - import {BLAH} from '.' and import {BLAH} from '..' do not work as expected, however import {BLAH} from './' and import {BLAH} from '../'do work correctly.
It seems this was a problem in 3.0.x too, however 3.0.x compiled and served the file with incorrect content and the error occured at runtime. However in the 3.1.0-pre.11 the file with problematic code now returns a 500 error, with an unhelpful error message.
Reproduction is available here.
I would expect the following source code:
import {value1} from '.';
import {value2} from '..';

import {value3} from './';
import {value4} from '../';

to compiile to:
import {value1} from './index.js';
import {value2} from '../index.js';

import {value3} from './index.js';
import {value4} from '../index.js';

In 3.0.13 it compiles to the incorrect output:
In 3.0.11 compiles to still incorrect
import {value1} from '.';
import {value2} from '..';

import {value3} from './index.js';
import {value4} from '../index.js';

In 3.1.0-pre.11 it errors during compile:
Error: Package(s) failed to build: Cannot find module '..' from '/Users/ben/src/github.com/BPScott/snowpack-test/bare-relative-import/package.json'

With v3.1.0-pre.11 the transform plugin hook seems to be ran on files in the app, on namespaced packages in node_modules (e.g. @shopify/react-html) but it is not triggered for packages without a namespace e.g. react-cookie.
Reproduction is available here.

Another regression: I've found a case where transitive dependencies don't seem to be honored and deduping of dependencies crosses major version boundaries.
Here's the reproduction.
This particular reproduction is slightly contrived, but where I ran into this with real-world code was with private packages that I wouldn't be able to share publicly.
In a project depending upon:

<EMAIL_ADDRESS><EMAIL_ADDRESS>which has a transitive dependency on<EMAIL_ADDRESS>
<EMAIL_ADDRESS>exposed uuid/v4 and uuid/v5 entrypoints that are not available in<EMAIL_ADDRESS>When running the snowpack dev server it gives me the error:
[14:02:58] [snowpack] +<EMAIL_ADDRESS>[14:02:58] [snowpack] └──<EMAIL_ADDRESS>[14:02:58] [snowpack] └──<EMAIL_ADDRESS>(dedupe)
[14:02:58] [snowpack] +<EMAIL_ADDRESS>[14:02:58] [snowpack] Package(s) failed to build: Package "uuid" exists but package.json "exports" does not include entry for "./v4".

This is seems to be because uuidv4 tries to load<EMAIL_ADDRESS>which does not expose the /v4 and /v5 entrypoints, instead of loading<EMAIL_ADDRESS>which does contain an uuid/v4 entrypoint.
I would expect that when building uuidv4 it would use uuid/3.4.0 and that when viewing generated output for uuidv4 in the browser I would see an import to referencing<EMAIL_ADDRESS>/v4 entrypoint.

Thanks you for the amazing effort and work you've put into snowpack @FredKSchott, much appreciated.
I think I may have found a regression in snowpack@next.
I updated from 3.0.11 to 3.1.0-pre.11. With React and Material UI 5 (mui) installed. On the latest version of snowpack there are no issues, however, with just the change to 3.1.0-pre.11, I now get the mui related runtime exception:
The requested module<EMAIL_ADDRESS>does not provide an export named 'getSliderUtilityClass'
I know you mentioned using namedExports above, but even that does not resolve this.
I tried variations of namedExports including sticking every cached mui option in there
  packageOptions: {
    namedExports: [
      "@material-ui/unstyled/SliderUnstyled",
      "@material-ui/unstyled/ModalUnstyled",
      "@material-ui/unstyled/BadgeUnstyled",
      "@material-ui/unstyled/BackdropUnstyled",
      "@material-ui/unstyled/Portal",
      "@material-ui/utils",
      "@material-ui/system",
      "@material-ui/styled-engine",
      "@material-ui/styled-engine",
      "@material-ui/styles",
      "@material-ui/core",
    ],
  },

Here's a repro. The main branch has the issue, however, the branch snowpack@latest seems to be ok.
Is there a way to retain the behavior from the latest version of snowpack for packages like this? Thanks

@FredKSchott this remains an issue: https://github.com/snowpackjs/snowpack/discussions/1756
Unfortunately dynamically imported packages (e.g. those imported via import(some_variable)) are still excluded from the build even if they are explicitly specified in knownEntrypoints.

Tested on an existing TypeScript projectReferences, Lerna, yarn workspaces setup
Repo
Observations/things I'm struggling with:

If i leave my setup as TS prefers it (build TS locally and export the .js for each package) then nothing happends when i start my main "app" snowpack package. E.g. i would expect it to build my local dependency package. Realized Snowpack probably not using the project references at all and wanted to reference source file directly to work properly. Replaced my imports from @namespace/lib to @namespace/lib/src/index worked fine or also replacing the main entrypoint in the package.json to point to my source  "main": "src/index.ts" also worked.
Is this the intention? Did i config my snowpack correctly? Is there any folder convetion here so i dont have to point my main to source?

I have not looked to deep into the ts plugin but out of the box i get no typechecking and no source maps. It seems to me as all files are just piped though to esbuild. Again, i must have missed something, but this repo is a fairly standard setup i would say so a bit supprised this didn't work "out of the box".

Happy to give any additional debug/help/feedback/test, just need to establish a baseline first so would very much appreciate some feedback on the repo.

@BPScott yea, old versions of uuid (pre-export map) don't seem to work with Node's CJS named import scanner and fail in ESM<>CJS envs. You can work around this by adding namedExports, but this package is so popular I think I'll go ahead and add it to always treat uuid as namedExports.
@theseyi thanks for the repro, I'll take a look.
@rmorshea good catch, I naively thought that we could get away from knownEntrypoints because of the new runtime package building, but you're right that import(var) still requires this for build(). I'll see about adding that back.
@Psvensso Can you share the TS project references that you mention? You can scroll up to earlier in this thread where I mention the snowpack:source package.json entrypoint that you can use, will definitely add docs for that before releasing so that it's more clear. Limited sourcemap support is a known limitation of the project (since no core maintainers currently use them in their main dev flow, it hasn't been prioritized. Looking for someone to help implement, if there is interest).
Looking forward to fixing this last batch of issues, and then merging to main! Thanks again to everyone who has helped debug and triage issues! (repro repos are 💯💯💯)

hmm, maybe I misunderstood your original issue. That's correct that both of those (named in v8, default in v3) should be possible without config

The console output is:
[14:02:58] [snowpack] +<EMAIL_ADDRESS>[14:02:58] [snowpack] └──<EMAIL_ADDRESS>[14:02:58] [snowpack] └──<EMAIL_ADDRESS>(dedupe)
[14:02:58] [snowpack] +<EMAIL_ADDRESS>[14:02:58] [snowpack] Package(s) failed to build: Package "uuid" exists but package.json "exports" does not include entry for "./v4".

From here two things jump out:

Why is<EMAIL_ADDRESS>marked as a dedupe? It is the only reference to that combo of package name, version and entrypoint (uuid, 3.4.0 and /v5 respectively) in whole dependency tree.
Package "uuid" exists but package.json "exports" does not include an entry for "./v4". is strange because the uuid/v4 path only exists in<EMAIL_ADDRESS>however 3.4.0's package.json does not contain an exports map - The exports map only exists in v8.3.2. It's not clear from the error but one of two things seem to be happening

When processing<EMAIL_ADDRESS>it tries to look at the package map from v8.3.2. I would have thought it should look for the package map from v3.4.0 - where there isn't a package map so there shouldn't be any limiting of entrypoints.
When processing<EMAIL_ADDRESS>it tries to create /v4 and /v5 entrypoints, those entrypoints aren't present in<EMAIL_ADDRESS>, only in<EMAIL_ADDRESS>I would have thought it should only use entrypoints from v8.3.2 - which is just the default entrypoint, no subpaths.

Thanks you for the amazing effort and work you've put into snowpack @FredKSchott, much appreciated.
I think I may have found a regression in snowpack@next.
I updated from 3.0.11 to 3.1.0-pre.11. With React and Material UI 5 (mui) installed. On the latest version of snowpack there are no issues, however, with just the change to 3.1.0-pre.11, I now get the mui related runtime exception:
The requested module<EMAIL_ADDRESS>does not provide an export named 'getSliderUtilityClass'
I know you mentioned using namedExports above, but even that does not resolve this.
I tried variations of namedExports including sticking every cached mui option in there
  packageOptions: {
    namedExports: [
      "@material-ui/unstyled/SliderUnstyled",
      "@material-ui/unstyled/ModalUnstyled",
      "@material-ui/unstyled/BadgeUnstyled",
      "@material-ui/unstyled/BackdropUnstyled",
      "@material-ui/unstyled/Portal",
      "@material-ui/utils",
      "@material-ui/system",
      "@material-ui/styled-engine",
      "@material-ui/styled-engine",
      "@material-ui/styles",
      "@material-ui/core",
    ],
  },

Here's a repro. The main branch has the issue, however, the branch snowpack@latest seems to be ok.
Is there a way to retain the behavior from the latest version of snowpack for packages like this? Thanks

@FredKSchott Should I move this to a new issue to track this? or do you prefer to keep the thread here regardless of the merge

@FredKSchott The project references are in the Repo i provided.
With the repo it does not build any dependency, it just seems to service it from cache.
https://github.com/Psvensso/react_mono_simple_starter_template/tree/snowpack
TS Project References doc

Found a strange error while testing this:
Build Result Error: There was a problem with a file build result.
⠧ watching for file changes...node:internal/process/promises:227
          triggerUncaughtException(err, true /* fromPromise */);
          ^

Error: /Users/megatron/FitCrunch/codebase/snowpack-test/src/Sub.svelte - Requested content ".css" but built .js.
    at FileBuilder.verifyRequestFromBuild (/Users/megatron/FitCrunch/codebase/snowpack-test/node_modules/snowpack/lib/index.js:111616:19)
    at FileBuilder.getResult (/Users/megatron/FitCrunch/codebase/snowpack-test/node_modules/snowpack/lib/index.js:111822:42)
    at Object.loadUrl (/Users/megatron/FitCrunch/codebase/snowpack-test/node_modules/snowpack/lib/index.js:130596:51)
    at async flushFileQueue (/Users/megatron/FitCrunch/codebase/snowpack-test/node_modules/snowpack/lib/index.js:130970:28)
    at async /Users/megatron/FitCrunch/codebase/snowpack-test/node_modules/snowpack/lib/index.js:131029:13
    at async onWatchEvent (/Users/megatron/FitCrunch/codebase/snowpack-test/node_modules/snowpack/lib/index.js:130742:9)
npm ERR! code 1
npm ERR! path /Users/megatron/FitCrunch/codebase/snowpack-test
npm ERR! command failed
npm ERR! command sh -c snowpack build

npm ERR!      /Users/megatron/.npm/_logs/2021-03-14T01_13_50_661Z-debug.log

/Users/megatron/.npm/_logs/2021-03-14T01_13_50_661Z-debug.log:
0 verbose cli [
0 verbose cli   '/Users/megatron/.nvm/versions/node/v15.5.0/bin/node',
0 verbose cli   '/Users/megatron/.nvm/versions/node/v15.5.0/bin/npm',
0 verbose cli   'run',
0 verbose cli   'snow'
0 verbose cli ]
1 info using<EMAIL_ADDRESS>2 info using<EMAIL_ADDRESS>3 timing config:load:defaults Completed in 1ms
4 timing config:load:file:/Users/megatron/.nvm/versions/node/v15.5.0/lib/node_modules/npm/npmrc Completed in 1ms
5 timing config:load:builtin Completed in 1ms
6 timing config:load:cli Completed in 1ms
7 timing config:load:env Completed in 0ms
8 timing config:load:file:/Users/megatron/FitCrunch/codebase/snowpack-test/.npmrc Completed in 0ms
9 timing config:load:project Completed in 0ms
10 timing config:load:file:/Users/megatron/.npmrc Completed in 0ms
11 timing config:load:user Completed in 0ms
12 timing config:load:file:/Users/megatron/.nvm/versions/node/v15.5.0/etc/npmrc Completed in 0ms
13 timing config:load:global Completed in 1ms
14 timing config:load:cafile Completed in 0ms
15 timing config:load:validate Completed in 0ms
16 timing config:load:setUserAgent Completed in 0ms
17 timing config:load:setEnvs Completed in 1ms
18 timing config:load Completed in 6ms
19 verbose npm-session 7c6e9d4dc02787bd
20 timing npm:load Completed in 10ms
21 timing command:run Completed in 7603ms
22 verbose stack Error: command failed
22 verbose stack     at ChildProcess.<anonymous> (/Users/megatron/.nvm/versions/node/v15.5.0/lib/node_modules/npm/node_modules/@npmcli/promise-spawn/index.js:64:27)
22 verbose stack     at ChildProcess.emit (node:events:376:20)
22 verbose stack     at maybeClose (node:internal/child_process:1063:16)
22 verbose stack     at Process.ChildProcess._handle.onexit (node:internal/child_process:295:5)
23 verbose cwd /Users/megatron/FitCrunch/codebase/snowpack-test
24 verbose Darwin 18.7.0
25 verbose argv "/Users/megatron/.nvm/versions/node/v15.5.0/bin/node" "/Users/megatron/.nvm/versions/node/v15.5.0/bin/npm" "run" "snow"
26 verbose node v15.5.0
27 verbose npm  v7.6.3
28 error code 1
29 error path /Users/megatron/FitCrunch/codebase/snowpack-test
30 error command failed
31 error command sh -c snowpack build
32 verbose exit 1

I've pushed the very simple demo project here in case anyone would like to repro: https://github.com/joehenry087/snowpack-test
Follow the readme instructions and then just change the contents of the "Sub" module and it will trigger this issue.
I've messed with the snowpack config and verified my node versions and all that... kind of out of options at this point. Would be interested to know if this is just a problem with my setup or with the new HMR work.
Also wanted to say thank you for putting together the new HMR watch stuff @FredKSchott

Ah, it seems if there is a svelte file that does not produce a stylesheet along with it, it will break. This may be an issue with the Svelte plugin rather than snowpack? I'll keep digging. This fixes the error:
<style>
    .test {
        background: red;
    }
</style>

<div class="test">
Test
</div>

@joehenry087 thanks for posting! I had thought that we found this bug originally and fixed it, will confirm its not a regression.

strange, I can't reproduce in your repo (npm install, npm start, then npm run snow = no errors in the CLI)

@FredKSchott just to confirm, you must then edit the src/Sub.svelte file to trigger the error.
If you did that and it works, it must be a problem with my node or npm or something...

It is odd that running npm run snow aka snowpack build doesn't produce the error the first time it builds. Only when editing the file it gets triggered... so maybe something to do with the watch aspect of the code.

I am having trouble finding any reference to a previous bug like this.

I can reproduce! Didn't realize it was only on save, but that made it easy to narrow down. Fixed in e9dfbac6, will go out in the next next release. Thanks again for letting us know

Brilliant! So glad this was an actual bug, usually it's just me derping on an incorrect configuration 😂

@FredKSchott regarding this:

NEW: Svelte package SSR support - Svelte packages can ship ".svelte" files in their package distribution, which means that packages are expected to build differently in SSR vs. non-SSR mode. Snowpack now supports this.

I have no issues building the appropriate client/server bundles for production (using @snowpack/webpack-plugin and custom setup). However, I'm using the SSR JS Api (runtime.importModule) and I cannot get all of the components to be SSR complient, no matter how I import them:
import EasyrouteProvider from 'svelte-easyroute/lib/EasyrouteProvider.svelte';
import RouterOutlet from 'svelte-easyroute/lib/RouterOutlet.svelte';

The local components work, but none of the components from node_modules dependencies imported by them are compatible:
<Link> is not a valid SSR component

Any thoughts? Has this been tested?

@FredKSchott  - trying the new release [3.1.0-pre13], as an improved support for linked dependencies is very much welcome (Thank You !). So far with little success.
My app was able to run under 3.0, with a couple of hacks to circumvent linked repositories however (see https://github.com/snowpackjs/snowpack/discussions/2700).
The dev server is unable to find some modules, as I get quite a lot of errors like:
[22:03:16] [snowpack] Server started in 4848ms.
[22:03:16] [snowpack] Local: http://localhost:8080
[22:03:16] [snowpack] Network: http://<IP_ADDRESS>:8080
[22:03:23] [snowpack] +<EMAIL_ADDRESS>[22:03:23] [snowpack] +<EMAIL_ADDRESS>[22:03:24] [snowpack] +<EMAIL_ADDRESS>[22:03:24] [snowpack] └──<EMAIL_ADDRESS>(dedupe)
[22:03:24] [snowpack] └──<EMAIL_ADDRESS>[22:03:24] [snowpack] +<EMAIL_ADDRESS>[22:03:25] [snowpack] +<EMAIL_ADDRESS>[22:03:29] [snowpack] +<EMAIL_ADDRESS>[22:03:30] [snowpack] +<EMAIL_ADDRESS>[22:03:30] [snowpack] └──<EMAIL_ADDRESS>(dedupe)
[22:03:30] [snowpack] +<EMAIL_ADDRESS>[22:03:31] [snowpack] +<EMAIL_ADDRESS>[22:03:31] [snowpack] └──<EMAIL_ADDRESS>(dedupe)
[22:03:32] [snowpack] Error: Cannot find module '@material/top-app-bar/foundation' from '/home/christophe/Programming/Polymer/preignition/node_modules/.cache/snowpack/development/<EMAIL_ADDRESS>    at Function.resolveSync [as sync] (/home/christophe/Programming/Polymer/preignition/node_modules/.pnpm/resolve@1.20.0/node_modules/resolve/lib/sync.js:102:15)
    at Object.resolveEntrypoint (/home/christophe/Programming/Polymer/preignition/node_modules/.pnpm/snowpack@3.1.0-pre.13/node_modules/snowpack/lib/index.js:43632:59)
    at Object.resolvePackageImport (/home/christophe/Programming/Polymer/preignition/node_modules/.pnpm/snowpack@3.1.0-pre.13/node_modules/snowpack/lib/index.js:54048:34)
    at resolveImport (/home/christophe/Programming/Polymer/preignition/node_modules/.pnpm/snowpack@3.1.0-pre.13/node_modules/snowpack/lib/index.js:53978:31)
    at /home/christophe/Programming/Polymer/preignition/node_modules/.pnpm/snowpack@3.1.0-pre.13/node_modules/snowpack/lib/index.js:53981:43
    at transformEsmImports (/home/christophe/Programming/Polymer/preignition/node_modules/.pnpm/snowpack@3.1.0-pre.13/node_modules/snowpack/lib/index.js:47911:37)
    at async Object.load (/home/christophe/Programming/Polymer/preignition/node_modules/.pnpm/snowpack@3.1.0-pre.13/node_modules/snowpack/lib/index.js:53980:23)
    at async loadUrl (/home/christophe/Programming/Polymer/preignition/node_modules/.pnpm/snowpack@3.1.0-pre.13/node_modules/snowpack/lib/index.js:130479:32)
    at async handleRequest (/home/christophe/Programming/Polymer/preignition/node_modules/.pnpm/snowpack@3.1.0-pre.13/node_modules/snowpack/lib/index.js:130710:28) {
  code: 'MODULE_NOT_FOUND'
}
[22:03:32] [snowpack] Error: Cannot find module '@material/top-app-bar/foundation' from '/home/christophe/Programming/Polymer/preignition/node_modules/.cache/snowpack/development/<EMAIL_ADDRESS>[22:03:32] [snowpack] [500]<EMAIL_ADDRESS>[22:03:32] [snowpack] +<EMAIL_ADDRESS>

Also, it seems that mounted routes are not working anymore when they contain symlinks.
This config is not working anymore,  as if __ is not mounted:
mount = {
 __: { url: '/__' }, // /__ is symlinked somewhere in node_modules
}

<script src="/__/firebase/8.2.9/firebase-app.js"></script>

Huh, that's odd. For some reason Snowpack is treating your preignition/node_modules/.cache/snowpack directory as a source file. Hard to say what's going on from the log, and idea why that may be happening?
Definitely not expected, at the very least we could explore adding an error to the source file builder if it looks like its trying to build a dependency.

@FredKSchott  - thanks a lot
I am trying (hard!) to understand what might be happening, and could reproduce on a simplified test app, by reintroducing dependencies one by one
setup, using pnpm:
workspaceRoot set to '../litElement' where my linked dependencies lies
test app:
dependencies": {
    "@material/base": "^10.0.0",
    "@material/mwc-tab": "^0.20.0",
    "@preignition/preignition-demo": "link:../litElement/preignition-demo",
    "@preignition/preignition-widget": "link:../litElement/preignition-widget",
    "lit-element": "^2.4.0",
    "lit-html": "^1.3.0",
    "router-slot": "^1.5.4"
  },

preignition-widget - some dependencies are also symlinked:
  "dependencies": {
<EMAIL_ADDRESS>a couple of them ...": "^0.20.0",
    "@preignition/lit-firebase": "link:../lit-firebase",
    "@preignition/preignition-mixin": "link:../preignition-mixin",
    "@preignition/preignition-state": "link:../preignition-state",
    "@preignition/preignition-styles": "link:../preignition-styles",
    "@preignition/preignition-util": "link:../preignition-util",
    "lit-element": "^2.4.0",
    "lit-html": "^1.3.0",
    "tslib": "^2.0.0"
  },

Now in preignition-widget I start to see the 'MODULE_NOT_FOUND' error when I import some @material dependency.
For instance, if this file importing @material/mwc-select is included in the preignition-widget export:
import { Select } from '@material/mwc-select';
import TwoWaySelectBinding from './two-way-select-binding.js';

/**
 * extension of mwc-textfield emiting a value-changed event when
 * value changes
 */
class PwiSelect extends
TwoWaySelectBinding(
        Select)))) {
  }
}

customElements.define('pwi-select', PwiSelect);

export { PwiSelect };

will generate :
[10:44:08] [snowpack] Error: Cannot find module '@material/mwc-ripple/ripple-handlers' from '/home/christophe/Programming/Polymer/snowpack-test/node_modules/.cache/snowpack/development/<EMAIL_ADDRESS>    at Function.resolveSync [as sync] (/home/christophe/Programming/Polymer/snowpack-test/node_modules/.pnpm/resolve@1.20.0/node_modules/resolve/lib/sync.js:102:15)
    at Object.resolveEntrypoint (/home/christophe/Programming/Polymer/snowpack-test/node_modules/.pnpm/snowpack@3.1.0-pre.13/node_modules/snowpack/lib/index.js:43632:59)
    at Object.resolvePackageImport (/home/christophe/Programming/Polymer/snowpack-test/node_modules/.pnpm/snowpack@3.1.0-pre.13/node_modules/snowpack/lib/index.js:54048:34)
    at resolveImport (/home/christophe/Programming/Polymer/snowpack-test/node_modules/.pnpm/snowpack@3.1.0-pre.13/node_modules/snowpack/lib/index.js:53978:31)
    at /home/christophe/Programming/Polymer/snowpack-test/node_modules/.pnpm/snowpack@3.1.0-pre.13/node_modules/snowpack/lib/index.js:53981:43
    at transformEsmImports (/home/christophe/Programming/Polymer/snowpack-test/node_modules/.pnpm/snowpack@3.1.0-pre.13/node_modules/snowpack/lib/index.js:47911:37)
    at async Object.load (/home/christophe/Programming/Polymer/snowpack-test/node_modules/.pnpm/snowpack@3.1.0-pre.13/node_modules/snowpack/lib/index.js:53980:23)
    at async loadUrl (/home/christophe/Programming/Polymer/snowpack-test/node_modules/.pnpm/snowpack@3.1.0-pre.13/node_modules/snowpack/lib/index.js:130479:32)
    at async handleRequest (/home/christophe/Programming/Polymer/snowpack-test/node_modules/.pnpm/snowpack@3.1.0-pre.13/node_modules/snowpack/lib/index.js:130710:28) {
  code: 'MODULE_NOT_FOUND'
}

If I remove this file or remove from the export or remove the import { Select } ... statement, snowpack dev server runs o.k.
Interestingly deduping some dependencies in the test-app (packageOptions.rollup.dedupe) was helping sometimes only. For instance I was able to still make test-app work by deduping @material/mwc-select and @material/mwc-list in the case above.
This workaround did not work in other instances. For instance, importing @material/mwc-textfield is causing the following error, which I cannot work-around either by deduping (or adding as dependencies ) @material/mwc-textfield or @material/texfield
[10:56:11] [snowpack] Error: Cannot find module '@material/textfield/foundation' from '/home/christophe/Programming/Polymer/snowpack-test/node_modules/.cache/snowpack/development/<EMAIL_ADDRESS>    at Function.resolveSync [as sync] (/home/christophe/Programming/Polymer/snowpack-test/node_modules/.pnpm/resolve@1.20.0/node_modules/resolve/lib/sync.js:102:15)
...
 {
  code: 'MODULE_NOT_FOUND'

I am also observing some weird stuff re lit-element directives.
First time I run the app (with --reload to clear the cache), the app fails to render, and:
[11:48:34] [snowpack] [Error: ENOENT: no such file or directory, open<EMAIL_ADDRESS>{
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path<EMAIL_ADDRESS>}
[11:48:34] [snowpack] Error: ENOENT: no such file or directory, open<EMAIL_ADDRESS>[11:48:34] [snowpack] [500] /_snowpack/pkg/lit-html.v1.3.0/common/lit-html-86410661.js
[11:48:34] [snowpack] +<EMAIL_ADDRESS>

Hard refreshing on the browser makes the app renders fined.
Also sometimes the until directive renders its own function as a string, as if duplicate lit-element were running on the browser.

Hey @FredKSchott had some time to test this lately and I want to say that it works pretty good, the only downside (that I think that it may be introduced with those changes) is yup not working (looks like the file is not generated correctly), there's a ticket here: https://github.com/snowpackjs/snowpack/issues/2945 but just wanted to link both tickets since seems that downgrading solves (except if you run a monorepo 😂)

@BPScott yea, old versions of uuid (pre-export map) don't seem to work with Node's CJS named import scanner and fail in ESM<>CJS envs. You can work around this by adding namedExports, but this package is so popular I think I'll go ahead and add it to always treat uuid as namedExports.
@theseyi thanks for the repro, I'll take a look.
@rmorshea good catch, I naively thought that we could get away from knownEntrypoints because of the new runtime package building, but you're right that import(var) still requires this for build(). I'll see about adding that back.
@Psvensso Can you share the TS project references that you mention? You can scroll up to earlier in this thread where I mention the snowpack:source package.json entrypoint that you can use, will definitely add docs for that before releasing so that it's more clear. Limited sourcemap support is a known limitation of the project (since no core maintainers currently use them in their main dev flow, it hasn't been prioritized. Looking for someone to help implement, if there is interest).
Looking forward to fixing this last batch of issues, and then merging to main! Thanks again to everyone who has helped debug and triage issues! (repro repos are 💯💯💯)

Hey @FredKSchott did you get a change to checkout the repro for this regression? Wanted to followup since someone else is reporting the same but I haven't tested out the latest and greatest


Add IMDS helper

Description of changes:
Adds /usr/bin/imds to handle the details of making IMDS requests.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Testing Done
TODO

@bwagner5 FYI I had to rework the test harness a bit to avoid the type of workaround we had for kubelet-config.json assertions.

do we have imds bins for ubuntu?


Expose port 4242 in Quickstart

The docker registry docs say to expose port 4242 as well as 8070, and the opentsdb exits without this port exposed.

I don't think opentsdb exits if that is not exposed, you just have no way of talking to it from the outside. Bosun should still be able to talk to it inside the container. Are you sure it actually is exiting for you without the port forwarded?

Yep. 100% sure, it was exiting with exit status 1; not expected and the OpenTSDB logs were saying TableNotFoundException: tsdb-uid simply restart with port 4242 exposed fixed everything.
Beside, the readme on the docker registry says to expose 4242: https://registry.hub.docker.com/u/stackexchange/bosun/
So that's inconsistent at least

sounds good. Thanks!


length

[Enter feedback here]
I saw the document mentioned
"This REST API is ideal for content providers that need to synthesize audio from text greater than 5,000 character (or more than 10 minutes in length)."
If I use SSML, will SSML tags be counted as characters?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: b69f7aec-e712-2d45-5dd4-9dd4a272454a
Version Independent ID: e5aea30a-d30d-45c0-7d8d-9411c0cf4d8e
Content: Long Audio API (Preview) - Speech service - Azure Cognitive Services
Content Source: articles/cognitive-services/Speech-Service/long-audio-api.md
Service: cognitive-services
Sub-service: speech-service
GitHub Login: @IEvangelist
Microsoft Alias: dapine

@lengyuan Thanks for the question. Can you please add more details about the question.

@lengyuan Thanks for the details. @IEvangelist Can you please confirm on this.

Hi @lengyuan,
Thank you for reaching out and asking this clarifying question, we appreciate these kinds of inquires. This is a great question, and one that I'm not actually certain of. I wanted you to know that I have reached out to the service team and asked them. I will let you know as soon as I hear back from them, and we will also update the docs to reflect this more concisely. Stay tuned...

Response has been provided.
#please-close

Thanks for the clarification.


M3-5450: Add LKE Premium checkbox to LKE Creation flow

Description

Adds HA Checkbox to LKE create flow
Adds new API methods for LKE updates
Removed __data__/kubernetes.ts and used a factory instead

TODO

[x] Feature flag
[ ] Finalize link in copy
[x] Properly calculate pricing
[x] Add and improve on unit tests

How to test

Run all Kubernetes unit tests

yarn test kubernetes

Test creating Kubernetes Clusters with and without HA enabled
If the price for HA shows up as $0.00, that is because that price is determined by data returned by the API, if you want the price to show a more realistic value, turn on the MSW

@DevDW The CORS error is probably just because the API work for this has not been completed yet.

Waiting for docs URL for copy.


It is not possible to copy text to clipboard from error message on development page.

When exception occurs development page is displayed in browser.
Sometimes it significantly increases productivity when it is possible to copy error text or sample message from error page.
For example for the following example I can just find RenderSection line in source:
         <!-- Styles -->
         @this.RenderSection("styles", required: false)
        </head>
        <body>
            @RenderBody()
        </body>
        </html>

But due to interactivity added to development page (all mouse events are handled) I cannot copy text to clipboard easy. So I have to extract it from HTML using firebug...
How can it be fixed/improved? What do you think?

Could you file this bug in the Diagnostics repo?

This issue was moved to aspnet/Diagnostics#319


imgs_circle's params

Thanks for your studies, that's helpful for me. But there's a problem which means I want to circle a image in npz, these code need a data_dir param, what means that?Waiting for your answer, really thanks

I substitute these parameters with paths as follows:
<CHECKPOINT.npz> : /home/jonsnow/svox2/opt/ckpt/my-first-exp/ckpt.npz
<data_dir> : /home/jonsnow/svox2/datasets/my-dataset-folder
I believe the dataset is used in the rendering process just to understand where the "up" vector of the scene is, so to correctly render the target upstanding as it was captured.


Adding hrim_sensor_forcetorque_msgs

Following same message structure as the Force sensor.

why is this repeat it?
uint8 MX=0
uint8 MY=1
uint8 MZ=2

and
uint8 FX=0
uint8 FY=1
uint8 FZ=2

Initially done with the focus of facilitating usage (not using definitions from a different file than the one used; not having to reference SpecsForceAxis when working with ForceAxis).
Modified naming for comprehension, removed duplicate declaration.


Removed Unused Fields

From #304:

90% of field_colour, field_date, field_dropdown, field_variable will have to be redone for new UI or integrating with Scratch. I think we should consider removing them at this time and pulling back pieces if/when we want them. Similarly, procedures.js?

At this point, actually, might make sense to leave them in and just tweak their designs. Except for field_date, which feels safe to take out.


Added a configurable limit to gets

Codecov Report

Merging #27 into master will decrease coverage by 0.29%.
The diff coverage is 66.66%.

@@            Coverage Diff            @@
##           master      #27     +/-   ##
=========================================
- Coverage   59.09%   58.79%   -0.3%
=========================================
  Files           5        5
  Lines         198      199      +1
=========================================
  Hits          117      117
- Misses         78       79      +1
  Partials        3        3

Impacted Files
Coverage Δ

main.go
12.19% <0%> (-0.16%)
:arrow_down:

primaryHandler.go
89.13% <100%> (ø)
:arrow_up:

deviceStatus.go
91.66% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ce99ffb...62cddef. Read the comment docs.


[DPE-5312] Update tracing charm libs to retrieve them from tempo coordinator repo

Issue
There are a bunch of tempo tracing related updates:

tempo-k8s has been deprecated in favor of tempo ha
tracing charm libs need to be fetch-ed from tempo_coordinator_k8s
tracing traffic is now relayed through grafana-agent-k8s (like the remaining COS traffic)

Solution

update tracing charm libs from new repo
Test integration with tempo ha + test relay of traffic through grafana-agent-k8s

To be done simultaneously
Update mysql-router-k8s tracing related documentation (in progress)

@shayancanonical what's holding merge here?

No hold up. Just slow to merge approved PRs


OS:18468078:Adding a check for the case where lambda method accessing super in global scope

When a labmda method access super property in the global scope the currentnonlambdafunc will be nullptr. This should be a SyntaxError.

LGTM

OS:18504733

Should this go in master?

@sethbrenith this is already in _plat. This PR is to port it to release/1.10.


Live Share Sync Problem

Product and Version [VS/VSCode]:
OS Version [macOS/Windows/Linux]:
Live Share Extension Version:
Target Platform or Language [e.g. Node.js]:
What were you doing when you encountered the desync?
How often have you encountered desyncs?

Hi @onurcanavci , thanks for reaching out to Live Share. We are tracking this desync issue in #3736. I am closing as duplicate, please add your comments and logs in #3736 and join the conversation there! You can access your logs via the Live Share: Export Logs command in the command palette.


Implement error correcting controller

Currently, a calculated trajectory can only be followed with use of the PD controller. A new controller that is able to control every rotor by itself and corrects errors has to be implemented.
Proposed course of action:

[ ] Get a first controller running that does not correct errors and controls Force/Torque
[ ] Calculate the speeds of the rotors and control the trajectory with them
[ ] Error correction

Does this PID controller look like something you were looking for?
https://github.com/utiasDSL/gym-pybullet-drones/blob/master/gym_pybullet_drones/control/DSLPIDControl.py

Thank you for the tip, that really looks awesome! The dynamics are even based on the Crazyflie, the same drone I used to test the implementation on.
Due to a shifted focus in my work I probably won't get to it anymore, but for anyone that uses the Crazyflie and wants to use this codebase, that might be worth looking into.


seo:check PHP Fatal error:  Class 'Mage' not found

When executing the seo:check with no parameters, I get the following fatal error:

PHP Fatal error:  Class 'Mage' not found in /path/to/.n98-magerun/modules/SEO_Checkup/src/SEOCheckup/Magento/Command/SEO/Check.php on line 34

The fatal error can be prevented by initializing Magento first. That call ensures the autoloader is properly initialized.


2 windows to create chart

after cloning and /installing and dev run
i get the 2 new topic windows
one is the default page
and one under it in darkmood

i just hid it  and it works fine now


Stuttering on loading shorts

When scrolling shorts, it loads the first frame, goes to black then start playing short.
Expected:
Either stay at first frame before it starts playing or show spinning before it starts playing
https://github.com/bcc-code/bcc-media-app/assets/88234679/75f270d0-6ccb-4398-9d88-1e0ee1e61f70

Fixed in 5.3.2 which ill try to put in the pipe tomorrow (Thursday) with #358 and #359