feat: serialised config #1106
feat: serialised config #1106
Conversation
ematipico
force-pushed
the
feat/serialised-config
branch
from
3ffacf1 to
835486a
Compare
|
I think this will be very useful. I don't really see the value of exporting them by feature though. Just client or server makes sense to me. |
| - `publicDir` | ||
| - `root` | ||
|
|
||
| **By "position"** |
There was a problem hiding this comment.
I think I prefer by position, it will probably be clearer for users as it will kinda follow the config shape
| - `root` | ||
|
|
||
| **By "position"** | ||
| - `astro:manifest/client`, exported bindings: |
There was a problem hiding this comment.
The client module should be available on server and client, for usecases like client:load
| - `build.format` | ||
| - `site` | ||
| - `redirects`[^1] | ||
| - `astro:manifest/server`, exposed bindings: |
There was a problem hiding this comment.
I think the server should contain all the data contained in the client module + server only data. I think it's a different situation than astro:env, so the choices made there should not apply here (ie. vars exposed from astro:env/client can be used on the server, but are not exposed on astro:env/server)
There was a problem hiding this comment.
I think the server should contain all the data contained in the client module
Can you provide a rationale for that? An explanation that doesn't involve a comparison with an existing feature
There was a problem hiding this comment.
I would treat /server as meaning "all serialisable config items that we think could be useful for devs and are happy making a stable API", with /client being the subset that is safe to expose in the browser. If the data might be useful in the client then it might be useful on the server too, so I see no reason to restrict that.
There was a problem hiding this comment.
I'm just a bit concerned/pedantic on having the same information in two modules.
Do you think it's fine to have them repeated?
There was a problem hiding this comment.
Yeah, I think it's fine. This isn't like z where it's mostly arbitrary: there's only one that can be used in each situation.
There was a problem hiding this comment.
there's only one that can be used in each situation.
/client can and should be usable server side, for cases where the code is on both server and client
|
|
||
| - The virtual modules will be "usable" via experimental flag. Attempting to use these virtual modules without the experimental flag turned on will result into a hard error. | ||
| - After a gracing period where we stabilise the APIs, the experimental flag will be removed. | ||
| - We will deprecate existing means to read this information. The following will be deprecated: |
There was a problem hiding this comment.
I think we should also deprecate Astro.site
There was a problem hiding this comment.
Keep them coming, it's possible I missed some of them
There was a problem hiding this comment.
Not deprecated but that also means for actions we won't need the trailing slash placeholder
There was a problem hiding this comment.
Also the internal i18n utilities
There was a problem hiding this comment.
It's going to help with a lot of these, and I'm sure all kinds of userland hacks that people have implemented. A much cleaner solution.
There was a problem hiding this comment.
Can this be moved to somewhere else? Mentioning deprecations belongs in Detailed design I would think, but definitely not in Testing Strategy.
|
Renamed module to |
| Proposed sub-paths | ||
|
|
||
| **By feature**: | ||
| - `astro:config/routing`, exported bindings: |
There was a problem hiding this comment.
Are you still proposing these subpaths?
There was a problem hiding this comment.
Not for this experimental release, but the proposal still there :)
Summary
Links