Skip to content

Support "Colocation" #602

@i-am-the-slime

Description

@i-am-the-slime

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.purs

Advantages

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 src with more dependencies than what's specified in spago.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 in src and tests in test
Oh actually I think this is possible
We have a package.files key that you can use to specify the files to publish

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions