snapcraft.io VS next-pwa

https://github.com/canonical/snapcraft.io please, stop spreading misinformation about snaps...

Don't like the "proprietarity" of snapcraft? OK, discard it and put flatpak. It will never be banned by Ubuntu. And yes, snapcraft.io available on github.

Probably not, since a feature request for this has been open since 2018.

snapcraft.io - the frontend website, is open source - https://github.com/canonical/snapcraft.io

What is the server code other than "something that distributes a .snap file"? Given that I can, if I want, take a .snap file to an airgapped machine and install it, it appears pretty trivial to offer alternatives to Canonical's infrastructure if anyone were particularly interested.

Snap store - aka snapcraft.io is already open-sourced under GPLv3., see here. Perhaps, you mean not that the code is closed-source but that Canonical won't relinquish any control to the community and will continue to enforce the snap ecosystem as an Apple-style walled-garden? If so, then I completely agree with that assessment. That IMHO is the core of what makes snap an inferior choice for the community.

snapcraft.io (e.g. snap store) has commits going back to Aug 16, 2017. Repo has GPLv3 license.

IMO this is mostly due to higher-ups at Canonical no longer giving a fuck about desktop, less so for the boots on the ground. Wimpress and Pope both left Ubuntu and I don't remember which one said it but one of the 2 had a tweet basically saying as much. But even without that, snaps have been around since at least Dec 11, 2014 and likely even earlier than that. But despite being around for over 8 years, there's still a bunch of common complaints and probably about 30-40% don't sound like they'd take a big company more than 6-12 months to address if they actually worked on it. Things like submitting a patch to the util-linux project to make cli tools like mount/blkid/lsblk/fdisk to make loop devices not be displayed by default (after all they effectively only "break" when snap is installed), following normal dot-prefix conventions in the $HOME folder, adding 1st party support for 3rd party repos (given the nature of FOSS, couldn't they even borrow the logic from flatpak?), adding optimizations to consume less disk space in the majority of scenarios. (I would say to also make snapcraft.io open-source, but after seeing this repo, it appears that common complaint may be off-base)

/** @type {import('next').NextConfig} */ const path = require("path"); const isDev = process.env.NODE_ENV !== "production"; const withPWA = require("next-pwa")({ dest: "public", disable: isDev, buildExcludes: ["app-build-manifest.json"], }); const generateAppDirEntry = (entry) => { const packagePath = require.resolve("next-pwa"); const packageDirectory = path.dirname(packagePath); const registerJs = path.join(packageDirectory, "register.js"); return entry().then((entries) => { // Register SW on App directory, solution: https://github.com/shadowwalker/next-pwa/pull/427 if (entries["main-app"] && !entries["main-app"].includes(registerJs)) { if (Array.isArray(entries["main-app"])) { entries["main-app"].unshift(registerJs); } else if (typeof entries["main-app"] === "string") { entries["main-app"] = [registerJs, entries["main-app"]]; } } return entries; }); }; const nextConfig = { experimental: { appDir: true, }, reactStrictMode: true, webpack(config) { if( !isDev ){ const entry = generateAppDirEntry(config.entry); config.entry = () => entry; } return config; }, }; module.exports = withPWA(nextConfig);

Thank you for trying it and asking questions. Let me reply to them below.

> Could you give a brief overview of how the project is built, or what libraries are used? I found two in the source, React and Workbox. I've never heard of Workbox before, and I'm still figuring out how service workers are used. But it seems like a big part of the source.

For building, I used Next.js with static generation, not using Server-side rendering. But it's not an important part because it doesn't rely on Next.js features so much.

About Workbox, the app uses them with next-pwa (https://github.com/shadowwalker/next-pwa) for providing caching strategies and offline behavior as Progressive Web App. For example, the app registers several precached files via Workbox. Precached files are fetched and cached by the service worker and these caches can be used while offline. Also, Workbox can configure runtime caching strategies. You can see details in Workbox documentation (https://developer.chrome.com/docs/workbox/).

The app also uses the Service Worker to connect IndexedDB as a local database and send HTTP requests to synchronize data with Google Drive. By using the Service Worker, these methods don't block the user interaction from the main thread and Service Worker can run in the background to synchronize data even if the browser window is suddenly closed.

We tried to use next-offline and next-pwa, but we were only able to precache the static assets.

It's possible that next-pwa might support precaching pages in the future. Subscribe to issue 252 to keep up to date on that.

I am currently using the opt-in integration for the CRA pwa. I kind of wanted to test out migrating to Next. I know NextJs has a pwa plugin. Does anyone have any experience migrating with this in mind (from cra to next)?

There's next-offline and next-pwa (and some comparison too). But has anyone here made a PWA with NextJS? Now I am not only referring to service workers/offline functionality, but also icons, adding to homescreen, manifest, and other PWA features. Does anyone have any good examples or guides to refer to?

next-pwa, for PWA support.

shadowwalker/next-pwa#132 improves error messages