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
Related to #1136, add a new command that sets up a subpackage. In other words, calling spago subpackage add <packageName> sets up the following:
creates a directory: ./<dir-name>/.
sets up a single purs file in ./<dir-name>/src/<file-name>.purs with content: module <module-name> where\n
sets up a spago.yaml file
package-name: the package name
dependencies - same as those used in spago init
For CLI args, I think we should support only 'additive' flags/args. So, a default subpackage is set up and one can further add to it with flags, but options to remove anything are not supported. This prevents bugs caused by an additive option and destructive option appearing simultaneously that otherwise conflict. In other words, the purpose of this command is to generate boilerplate and then let a user modify each part as needed, not to support all possible options on the CLI.
Keeping it small, here's what comes to mind:
--dir-name - the name of the directory to use here: ./<dir-name>/. When unspecified, uses the package-name.
--file-name - the name of the file to use here: ./<dir-name>/src/<file-name>.purs. When unspecified, we use the package name by converting foo-bar into FooBar.
--include-tests - a .<dir-name>/test/Test/<file-name>.purs file is generated and with same content as spago init's test code and a corresponding test config in spago.yaml. When unspecified, a test dir and config section is not included.
--module-name - the file generated in src (and test if --include-tests is set) use this module name (e.g. module <module-name> where). When this value is unspecified, uses a derivation of the package name (e.g. foo-bar -> FooBar).
The text was updated successfully, but these errors were encountered:
I think it's good to have something like this, but I'd like to have it under spago init --subpackage PKG.
And we can likely start with a smaller amount of flags, in the sense that I think there's little point to fix these things for the user since they are a file edit away. I'd only keep --directory, derive everything else from the package name, and include tests anyways (like spago init does)
Related to #1136, add a new command that sets up a subpackage. In other words, calling
spago subpackage add <packageName>
sets up the following:./<dir-name>/
../<dir-name>/src/<file-name>.purs
with content:module <module-name> where\n
spago.yaml
filepackage-name
: the package namedependencies
- same as those used inspago init
For CLI args, I think we should support only 'additive' flags/args. So, a default subpackage is set up and one can further add to it with flags, but options to remove anything are not supported. This prevents bugs caused by an additive option and destructive option appearing simultaneously that otherwise conflict. In other words, the purpose of this command is to generate boilerplate and then let a user modify each part as needed, not to support all possible options on the CLI.
Keeping it small, here's what comes to mind:
--dir-name
- the name of the directory to use here:./<dir-name>/
. When unspecified, uses the package-name.--file-name
- the name of the file to use here:./<dir-name>/src/<file-name>.purs
. When unspecified, we use the package name by convertingfoo-bar
intoFooBar
.--include-tests
- a.<dir-name>/test/Test/<file-name>.purs
file is generated and with same content asspago init
's test code and a correspondingtest
config inspago.yaml
. When unspecified, atest
dir and config section is not included.--module-name
- the file generated insrc
(andtest
if--include-tests
is set) use this module name (e.g.module <module-name> where
). When this value is unspecified, uses a derivation of the package name (e.g.foo-bar
->FooBar
).The text was updated successfully, but these errors were encountered: