Yeah admittedly I hadn't thought about how this interacts with the environment API. On `version-3` we just override the `fix_stack_trace` implementation during dev
It's just a difference of opinion between stack traces and sourcemaps — `new Error().stack` will always contain 1-based line/columns but sourcemaps contain 0-based ones
ah yep, leftover from an earlier change
- feat: add `$app/manifest` module
Should probably also rename `Pathname` to `Path`, since `Pathname` suggests `url.pathname` which this isn't. Also it aligns with the `path` properties in the manifest
- feat: add `$app/manifest` module
Actually you know what? This could be how we distinguish route IDs from pathnames in `resolve`. This makes way more sense to me: ```js // valid resolve('path/to/somewhere'); resolve('/path/to/[locati…
thank you!
- docs: show a reliable way to preload fonts
Hmm. I wonder if we should provide a `name` property that represents the original basename. Only for `font` and `asset` types, since JS/CSS is bundled. We probably wouldn't even need a lookup, since …
- Add a more straightforward method of opting dynamic explicit environment variables out of build-time validation
How could such a thing work?
- feat: add `$app/manifest` module
Renamed `build` to `immutable` and `files` to `assets`. Couple of wrinkles: - `immutable` contains a non-immutable file, namely `_app/manifest.js` itself. Which is weird. I guess we could move it to …
```suggestion feat: add `$app/manifest` module with `immutable`, `assets`, `prerendered`, and `routes` exports ```