You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For both routes and components, it could be interesting to have an option to import them from another route or component for reusability without using relative imports, which are brittle.
Consider the following route in e.g. routes/base/add-head.js
// PROPOSED: not an actual route: do NOT map requests to `/base/add-head` to thisexportconstvirtual=true;exportdefaultroute=>({head(){// return stuff like headers},// add all HTTP verbs from route (this could contain an overriding `head` verb)
...route,});
This would allow any route to add a HEAD verb to it.
The same could be done with components, to allow reusing base components from anywhere within the components directory.
In itself, the app identifier means nothing (unless you're using the npm package app). But with the new build system, where we put everything inside build, we could add a package.json file there that defines
For both routes and components, it could be interesting to have an option to import them from another route or component for reusability without using relative imports, which are brittle.
Consider the following route in e.g.
routes/base/add-head.js
And then in another route:
This would allow any route to add a
HEAD
verb to it.The same could be done with components, to allow reusing base components from anywhere within the
components
directory.In itself, the
app
identifier means nothing (unless you're using the npm packageapp
). But with the new build system, where we put everything insidebuild
, we could add apackage.json
file there that definesFor the client-bundling, we'd need to pass in a dynamic tsconfig with
paths
to esbuild.The text was updated successfully, but these errors were encountered: