-
Notifications
You must be signed in to change notification settings - Fork 80
Closed
Description
I am a big fan of colocation.
Example
In my specific case this implies I can keep a `Spec.purs` and a `Story.purs` as descendents of `/src/`.
For example, I would like to be able to structure my project similarly to this
$> tree src
.
├── Yoga
│ ├── Block
│ │ ├── Atom
│ │ │ ├── Button
│ │ │ │ ├── Story.purs
│ │ │ │ ├── Style.purs
│ │ │ │ ├── Types.purs
│ │ │ │ └── View.purs
│ │ │ ├── Button.purs
│ │ ├── Molecule
│ │ │ ├── Sidebar
│ │ │ │ ├── Spec.purs
│ │ │ │ ├── Story.purs
│ │ │ │ ├── Style.purs
│ │ │ │ └── View.purs
│ │ │ ├── Sidebar.pursAdvantages
I can see quickly which files have a corresponding test (Sidebar has one, but Atom doesn't). Both have a Story.
I do not need to keep the module structure between test and src.
Thus, I can easily delete or move all files relating to some functionality.
From what I can tell, this is necessary:
- 1. Allow excluding files from the package (e.g.,
*Spec.purs) - 2. Allow building what's in
srcwith more dependencies than what's specified inspago.yaml
Possible solution to 1:
Quoting @f-f on Discord:
Yeah there are no globs to be specified in the new spago
Everything is by convention: sources are insrcand tests intest
Oh actually I think this is possible
We have apackage.fileskey that you can use to specify the files to publish
Metadata
Metadata
Assignees
Labels
No labels