0.29 planning

[benmccann]

I would like to propose the following breaking changes for 0.29:

• Remove segment prop from layouts (RFC: Remove segment prop from layouts #824)
• Fix service-worker.js: "Uncaught (in promise) TypeError: Request failed" on export with relative path #1441 / When building sapper with basepath, files and shell of service-worker does not include basepath #1538 / Service worker files to cache don't include base path #1692. One possible fix might be to revert Prefix file paths in SW manifest with a slash #1244 though I'm not quite sure how the service-worker.js in the template would need to be updated. Or possibly we could prepend the basepath in the manifest which would not be a breaking change and would not require the template to be updated. That might be easier/safer, but could result in a slightly larger manifest (though I'm not sure it'd matter after compression)
• Remove Rollup CSS handling plugin. It's now nicely contained in a plugin that doesn't touch any other code. I recently
  converted rollup-plugin-css-chunks to TypeScript and would like to take a look at integrating our plugin there. See the RFC for full details: Splitting out Sapper's CSS handling rfcs#29 - SvelteKit as planned will not allow this. Better to keep Sapper aligned
• DONE - Upgrade rollup-plugin-css-chunks (Upgrade rollup-plugin-css-chunks #1666)
• DONE - sapper:prefetch (Change rel=prefetch to sapper:prefetch #1566)

[Conduitry]

I believe there are people currently using the fact that segment is undefined on error pages as a workaround for detecting that situation, so I think it would be nice to expose this information officially on the $page store in the same version as we remove segment. There's a PR open for this, but I have not looked at what it does or how it does it.

[benmccann]

Ah, good call out. That PR looks pretty solid. I'll probably merge it after one more review iteration

[UltraCakeBakery]

Please leave #824 open for discussion. Maybe even move this to the next release. I think we should first see some real world examples, side by side, to make sure this change doesn't unnecessarily increase the codebase of your average (and/or more complex) sapper application.

[TheComputerM]

The segment prop is useless and can be easily replaced with $page.path which has nested route support (such as '/path1/path2').

After thinking about it, I do not have any problem with segment, but how layouts work. It would be better if sapper has layouts that work similarly to nuxtjs.

[UltraCakeBakery]

The segment prop is useless and can be easily replaced with $page.path which has nested route support (such as '/path1/path2').

When marketing Svelte people often make the point that the amount of bugs in your project increases as your codebase grows. This is why I would like to see a real world example before we make changes like this. If this way of doing things increases the amount of code we have to write, removing the segment prop would be a total waste. Its presence is and/or does not have to hurt anyone.

NASA wouldn't launch a rocket without testing each individual part and group of parts separately. We shouldn't either.
Especially when it is a breaking change like this one that will require people to possibly rewrite a lot of small parts of code.

[TheComputerM]

Here: https://svelte-materialify.vercel.app/getting-started/installation/
The highlighting of left navigation items is taken care of using the page store.

[UltraCakeBakery]

Here: https://svelte-materialify.vercel.app/getting-started/installation/
The highlighting of left navigation items is taken care of using the page store.

In some other components of the docs you still use 'segment'. Idk if you've committed the changes already.
https://github.com/TheComputerM/svelte-materialify/blob/master/packages/docs/src/routes/_layout.svelte

Imagine a application with a sidebar, a top navigator, secondary top navigator, both navigators having multiple modals and dropdowns each being their own component, a footer with differently styled sitemaps, bla bla bla.
One simple sidebar isn't a good example because often applications have more than that.

Ofc there is also the fact that if you have an application like this segment may not always be sufficient. I get that. But that is exactly why I want to see a real world example of an application that has slightly more going on. The changes being in 1 simple commit would be ideal so we can compare the amount of code and if the tradeoff is worth it.

[jacob-8]

I upvote the "Remove trailing slash from service worker manifest" as it has broken my references to global.css, as I reference them like this global.css?v=TIMESTAMP. My stylesheets don't load anymore after the service worker has been activated. The bug can reproduced by simply adding on "?v=2" to the reference to global.css in template.html.

[arekbartnik]

@benmccann how about #1427 ? :)

[UltraCakeBakery]

@benmccann how about #1427 ? :)

Looking forward to this one too. Also the other pull that adds the 'focus' event listener.
edit: #921

[b1mind]

Remove leading slash from service worker manifest by reverting <-- please and thank you ! 👍

Needs to base it self off the url given in server.js

[TheComputerM]

Also, after working with both rollup and webpack in sapper, better support for webpack would be beneficial as webpack provides inbuilt HMR and better bundling.
Even Rich Harris has written that Use webpack for apps, and Rollup for libraries
Maybe integration with snowpack would be easier with better webpack support?