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
When picking constants values in the config, now that the location property can be associated to Knifecycle initializers, we could instead of stringifying constants, directly import it from the config file:
That said, it would necessit to not use the default export but instead use named exports to be able to load the configurations via Knifecycle builds, leading to the same problem that the following issue needs : whole module typing.
A side effect of it would be that the configuration constants, currently stringified by the build, would now be dynamically assigned (so any logic inside it would also operate in the build, ie reading env to selectively enable a config). Not sure it is a good or bad thing. Need some thinking before deciding.
The text was updated successfully, but these errors were encountered:
When picking constants values in the config, now that the location property can be associated to Knifecycle initializers, we could instead of stringifying constants, directly import it from the config file:
whook/packages/whook/src/services/_autoload.ts
Lines 196 to 202 in 75132c3
That said, it would necessit to not use the default export but instead use named exports to be able to load the configurations via Knifecycle builds, leading to the same problem that the following issue needs : whole module typing.
A side effect of it would be that the configuration constants, currently stringified by the build, would now be dynamically assigned (so any logic inside it would also operate in the build, ie reading env to selectively enable a config). Not sure it is a good or bad thing. Need some thinking before deciding.
The text was updated successfully, but these errors were encountered: