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
{{ message }}
This repository has been archived by the owner on May 5, 2024. It is now read-only.
Currently it is possible to apply the same composer multiple times to a project. Additionally, we don't have a way to detect if a composer is supported on the current computer (external dependencies installed, see tauri which requires rust)
Describe the solution you'd like
I have previously already added some types to get a feeling for all components of a composer. The types are not accurate and do not provide any meaningful enhancements. Everything needs to be re-thinked.
Preconditions
Preconditions need to ensure that a given composer can be used within the given environment. This is especially useful, when considering composers that require some other globally installed tooling to work correctly (#9). Preconditions are workspace independent and can only check for the global environment.
Here is a sample pre installation check to determine if the Tauri adder could be installed:
exportconstchecks=defineComposerChecks({
options,preconditions: [{name: "rust installed",run: ({ execute })=>{// execute a shell command and gather it's output and exit codeconst{ output, exitCode }=execute("cargo",["version"]);// if the exit code is 0, we can assume that cargo / rust is installed correctlyreturnexitCode==0;},},],preInstallation: [],postInstallation: [],});
Precondition checks should be executed before the composer runs to avoid unnecessary file modifications in case any of the preconditions fails. In case at least one precondition fails, the composers should not install itself and rather fail. The user should be notified with an appropriate error message.
Pre installation checks
Pre installation checks are executed before the adder executes, but after the project has been detected / created and therefore have full access to the workspace (minus the options, as they have not been chosen yet). These checks should identify if
the composer is supported in the current environment (svelte / kit)
the composer has already been applied or the tool to compose is already setup (i.e. the tailwdincss.config.js file is already present / installed packages already present)
Post installation checks
Should check if a composer was successfully installed, basically they are the same as the pre installation checks, but they are executed after a composer was executed to determine if everything was set up as expected.
Further thoughts
Those ideas are mainly taken from svelte-add (predecessor of svelte-compose) and need to be partially re-thought.
Do we really need the post installation checks?
Is there any reason we would not trust in our code? Additionally we have tests that run when merging PR's that ensure that alle test execute correctly. Those tests not only check that that special files are present and contain special contents, but run explicit integration tests for each possible composer and svelte template possibility.
Do we really need pre installation checks?
Once we got this far, let's think if we need pre installation checks. Should they be optional? For most composers it should be enough to check if any of the dependencies is already present. But what if we have something like #18 (Github pages) that does not apply a dependency? Should we provide pre build checks for checking the dependencies? How should the method definition of those look like?
The text was updated successfully, but these errors were encountered:
Topic
core, tests
Description
Currently it is possible to apply the same composer multiple times to a project. Additionally, we don't have a way to detect if a composer is supported on the current computer (external dependencies installed, see
tauri
which requiresrust
)Describe the solution you'd like
I have previously already added some types to get a feeling for all components of a composer. The types are not accurate and do not provide any meaningful enhancements. Everything needs to be re-thinked.
Preconditions
Preconditions need to ensure that a given composer can be used within the given environment. This is especially useful, when considering composers that require some other globally installed tooling to work correctly (#9). Preconditions are workspace independent and can only check for the global environment.
Here is a sample pre installation check to determine if the Tauri adder could be installed:
Precondition checks should be executed before the composer runs to avoid unnecessary file modifications in case any of the preconditions fails. In case at least one precondition fails, the composers should not install itself and rather fail. The user should be notified with an appropriate error message.
Pre installation checks
Pre installation checks are executed before the adder executes, but after the project has been detected / created and therefore have full access to the workspace (minus the options, as they have not been chosen yet). These checks should identify if
tailwdincss.config.js
file is already present / installed packages already present)Post installation checks
Should check if a composer was successfully installed, basically they are the same as the pre installation checks, but they are executed after a composer was executed to determine if everything was set up as expected.
Further thoughts
Those ideas are mainly taken from
svelte-add
(predecessor ofsvelte-compose
) and need to be partially re-thought.Do we really need the post installation checks?
Is there any reason we would not trust in our code? Additionally we have tests that run when merging PR's that ensure that alle test execute correctly. Those tests not only check that that special files are present and contain special contents, but run explicit integration tests for each possible composer and svelte template possibility.
Do we really need pre installation checks?
Once we got this far, let's think if we need pre installation checks. Should they be optional? For most composers it should be enough to check if any of the dependencies is already present. But what if we have something like #18 (Github pages) that does not apply a dependency? Should we provide pre build checks for checking the dependencies? How should the method definition of those look like?
The text was updated successfully, but these errors were encountered: