snowpack build --watch mode

[FredKSchott]

Original Discussion: https://www.pika.dev/npm/snowpack/discuss/257 /cc @1player, @FredKSchott

snowpack dev is great in some cases, but with some server-side frameworks actually creating and rebuilding asset (files) as source files change is necessary.

I'd really like to adopt snowpack in my projects that are currently running webpack build --watch.

[stramel]

I'm wondering if this is actually a feature we need to bake in or if we should just rely on some third-party tooling to achieve this functionality.

I think you could simply get away with something like this:

npm i -g nodemon
nodemon --watch src --exec "npm run build"

Personally, I have very rarely come across a case where I need to fully re-build the production version of my app.

[FredKSchott]

Thanks for that snippet, I'm sure someone will find that useful.

The usecase that I'm aware of is when you need to own the server and can't use snowpack dev directly (see discussion above).

One update would be that we do now have better proxying support, which could help some users who were stuck before. https://www.snowpack.dev/#project-relative-imports

[tbroyer]

Personally, I have very rarely come across a case where I need to fully re-build the production version of my app.

That's not the goal. The goal is snowpack dev except with the files (at a minimum the entry points) written to disk so they can be served by a separate server, and with livereload. Think of it like snowpack watch rather than snowpack build --watch.

My use case is the HTML host page is behind authentication, and/or might also be generated (e.g. to seed data related to the authenticated user).
Authentication redirects to a login page, sometimes on another server (single sign on), so having snowpack dev serve the page is a deal breaker, and it looks like it's not possible to proxy everything but have the Snowpack server otherwise serve everything that it manages. For now I'm using parcel watch which does the job, and having this feature here would allow me to try out Snowpack on my projects.

Fwiw, an approach like GWT's superdevmode would work for me: write the entry points to disk and serve everything else by a server with Access-Control-Allow-Origin: *, those files can even be "stubs" that import/@import the actual entry points from the dev server. Livereload / HMR would be a big plus (Parcel does it, so it's technically possible).

[s3ththompson]

I would really like to adopt snowpack and I'm waiting for this feature as well!

I'm working with a server-side app that runs inside Vagrant. The best practice for local development with Vagrant is to mount your source code with NFS inside the Vagrant VM and run your watch / build command on the host (outside the VM). Then the server inside Vagrant serves the assets as they are changed / written to disk. (This also means that the http proxy options are less than ideal for me.)

As @tbroyer mentions above, this should probably be snowpack watch rather than snowpack build --watch since I don't want to run the full production build, but rather the dev build, just written to disk rather than served from memory.

I am considering writing a custom watch script in the interim.

[s3ththompson]

Hmm, I guess another alternative is making snowpack more easily consumable as an API (rather than rely on the CLI to accomplish everything...) allowing this sort of thing to live in userland.

[chuanqisun]

In my use case, the html page is a web view hosted inside an Electron app. snowpack watch mode seems to be good fit. It won't be as good as in memory HMR but is it much better than rerunning the build upon each file change event. It feels like snowpack already has the capability to watch the files, we just need to dump its memory into filesystem

To achieve HMR for Electron, I'd imagine a plugin similar to https://github.com/electron-userland/electron-webpack, and that is definitely beyond the scope of this project.

UPDATE:

I just figured I can request content from the snowpack dev server from Electron shell. No need for watch mode.

<script type="module" src="http://localhost:8080/_dist_/index.js"></script>

[francislavoie]

Just to give my :+1: for a snowpack watch type of solution as well (files continually written to disk, no server), that's what I would want as I described in this discussion thread https://www.pika.dev/npm/snowpack/discuss/508

[dzirg44]

Really looking forward to have this! It can be very useful when we build CLI node apps\utils.

[refactornator]

I need this feature to start using snowpack. I have a java spring boot app, which hosts my react app and I just need to watch my source files with snowpack and dump them into a directory that my spring boot app will serve whenever the source changes. snowpack install doesn't write the import paths I need, and snowpack dev starts an additional server I don't need.

Additionally, I haven't found any way to specify a different directory than src to look in for my index.jsx file. I feel like I must be missing something really obvious, but mount doesn't do that, and there's no option I see for specifying the entry point. Am I missing something?

[FredKSchott]

@wlindner not entirely sure that I follow, Snowpack will mount directories (like src/) to different urls (like /_dist_/*) and then any file within the src/ folder will be accessible at the /_dist/* url. The dev output should help you see what it's looking for and where.

[FredKSchott]

18 👍 's can't be wrong :) Let's prioritize this! I created a PR with a first draft of this feature: #782 If anyone is excited to get this working and able to help out, I'd love your help testing that PR.

[FredKSchott]

Merged in #782! Available to test now via npm install snowpack@next

https://twitter.com/pikapkg/status/1294372030360334336

[refactornator]

Very cool! Thanks for the quick turnaround, I installed the next version of snowpack and my initial impression is that it's mostly working.

I keep getting a crash and I'm not sure how to reproduce it (sorry 😞). --log-level isn't working, so I just know the exit code was 1. It seems to happen when I've run snowpack build --watch multiple times. And I think when I've run snowpack build in between watch builds. The crash goes away if I clean up the build directory. It might be relevant that I'm using a custom "out" option in the "devOptions" in my snowpack config. PS: I wish "out" wasn't a part of "devOptions". It changes the output directory of builds. It seems more like a build option. That is confusing.

I'm also surprised how slow it is. I set up my project with a single index.jsx file which only renders a div with some text in it. When I make a very simple change to that text, the log says "File changed" many more times than I would expect. This is what I see in the console when 1 file is changed.

> snowpack build --watch

[snowpack] ! building source…
[snowpack] log is not a function
[snowpack] ✔ build complete [0.82s]
[snowpack] Watching for changes...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...
[snowpack] File changed...

Let me know if you need any additional info, I'm happy to help out how I can!

[refactornator]

Whoops, I figured out why I was getting all of those "File changed" log messages. It has to do with the folder structure I was using and that the output of my build was changing files in my src directory. This is not an issue with the snowpack build --watch code and is more of an issue with how snowpack defaults to including "src" and "public" folders during build. I started a discussion here: https://github.com/pikapkg/snowpack/discussions/814

[FredKSchott]

Awesome, thanks for spinning up the discussion! We have some logging improvements going on right now as well, as soon as we get those merged we'll cut a new release

[silverwind]

I wonder if it'd make sense to also have a snowpack dev --watch that outputs only to the file system and never starts up a web server. I could see it being useful when build becomes too slow.

[francislavoie]

How is that different from snowpack build --watch @silverwind? It does exactly that.

[silverwind]

Excuse me, I've not tried build --watch yet. I thought build implies minfication and bundling which dev would not do.

[francislavoie]

build is configurable, you can disable minification and bundling if that's what you prefer. https://www.snowpack.dev/#configuration

[silverwind]

Thanks. I see this is probably what I want:

NODE_ENV=development yarn -s run snowpack build --watch --no-minify --no-bundle

[DrSensor]

Unfortunately either:

NODE_ENV=development snowpack build --watch --no-minify --no-bundle

or

snowpack build --watch --no-minify --no-bundle --env NODE_ENV=development

or

NODE_ENV=development snowpack build --watch --no-minify --no-bundle --env NODE_ENV

doesn't override import.meta.env specified in build/__snowpack__/env.js 😢

[manzt]

Sorry if I'm being naive here, but is it possible to run snowpack build --watch without needing to install all dependencies each time?

I ask because the dev experience is much better for snowpack dev where web_modules are only installed the first time, and restarting snowpack dev is nearly instant. But with snowpack build --watch, you have to pay for the upfront install each time you restart.

EDIT: It seems https://github.com/snowpackjs/snowpack/issues/1052 will have the desired effect.

[erlandsona]

Unfortunately either:

NODE_ENV=development snowpack build --watch --no-minify --no-bundle

or

snowpack build --watch --no-minify --no-bundle --env NODE_ENV=development

or

NODE_ENV=development snowpack build --watch --no-minify --no-bundle --env NODE_ENV

doesn't override import.meta.env specified in build/__snowpack__/env.js

Also having this behavior with the latest v3 release... trying to use snowpack build because elm-live is a much nicer dev experience for Elm than what snowpack can currently support with the elm plugin. But I cannot for the life of me force NODE_ENV/MODE to propagate through to public/_snowpack/env.js

:confused:

[yalpertem]

When I try the build in --watch mode, I get an internal parse error. The regular build and start scripts work without errors. I couldn't understand the reason from the logs, anyone encountered a similar error?

[12:56:34] [snowpack] Parse error @:1226:3
[12:56:34] [snowpack] Error: Parse error @:1226:3
    at parse (/.../node_modules/snowpack/node_modules/es-module-lexer/dist/lexer.cjs:1:402)
    at Object.scanCodeImportsExports (/.../node_modules/snowpack/lib/cjs/rewrite-imports.js:21:29)
    at /.../node_modules/snowpack/lib/cjs/sources/local.js:587:59
    at async PackageSourceLocal.buildPackageImport (/.../node_modules/snowpack/lib/cjs/sources/local.js:454:30)
    at async PackageSourceLocal.resolvePackageImport (/.../node_modules/snowpack/lib/cjs/sources/local.js:691:9)
    at async resolveImport (/.../node_modules/snowpack/lib/cjs/sources/local.js:303:20)
    at async /.../node_modules/snowpack/lib/cjs/sources/local.js:306:37
    at async /.../node_modules/snowpack/lib/cjs/rewrite-imports.js:47:31
    at async Promise.all (index 19)
    at async transformEsmImports (/.../node_modules/snowpack/lib/cjs/rewrite-imports.js:39:5)

[francislavoie]

@yalpertem snowpack is essentially unmaintained at this point, I suggest switching to vite instead.

[yalpertem]

@yalpertem snowpack is essentially unmaintained at this point, I suggest switching to vite instead.

Thanks for the notice, my bad that I didn't check it first.