Workspaces -> .lona project "files"

[ryngonzalez]

Proposal

To make it easier to share, think about, and work with design system workspaces, we should consider converting the concept of these workspace folders to .lona project "files".

A Single Unit

One of the more confusing aspects of Lona currently is the lack of transparency around "workspaces". While #11 should make it easier to work with workspaces, indicating that you need to create a workspace to get started and making it easy to pick a workspace for a session. Talking about these as self-contained projects/files will make it more clear what the mental-model is. Rather than some random folder, you're working with a project "file", which happens to have other files in it.

Searchable

Will make it easier to search for these projects. find *.lona is easy peasy.

Accessibility to editing

We still want to maintain clear, open access to editing the contents of a workspace in other tools. We can make it clear that a Lona project is just a set of text-editable documents by leaving them as visible folders in the file system browser.

One inspiration for the .lona format is how Framer creates .framer "files" for their projects, which demonstrates this behavior:

This is also similar to working with Xcode projects/workspaces.

[dabbott]

This seems like the right UX for what we're doing. We would do this using mac document packages, right?

This seems all positive, but what are the downsides to doing it this way?

I remember Sketch files were like this at one point but aren't anymore. For Sketch files it didn't make as much sense since they weren't individually editable, and it made it harder to share via email or Dropbox. I'm sure people will try to share Lona workspaces via slack, but that's not really a use case I want to optimize for, so I don't think we'll have the same problems as Sketch.

[haswalt]

Looking at workspaces and project files in Xcode you have several individual files in your "project" or "workspace" but they are linked into a collection or "project" by the xcodeproj file.

In most cases users of Lona would be generating code for projects that aren't contained in a single file so multiple files here isn't a problem IMO.

I feel something well defined, diffable and therefore suited to version control is most important.

[MattKevan]

Not sure if it's the same as a document package, but what about a similar file format to Sketch, where .sketch files are actually zips? This means sketch files can be easily manipulated by other programs, as well as being stored in version control etc.

[dennislaupman]

@dabbott Maybe it's an good idea to add small thumbs/png's of the components in a preview folder. So we don't have to render them in the workspace overview

[GuillaumeSalles]

I definitely see a lot of benefits to package a workspace in a .lona file.

A workspace can be corrupted by moving a component file or an asset. A .lona file can help to ensure the workspace consistency.

It could contain a "workspace specification version" to help the migration process after a breaking change in the spec.

If a .lona file is a single unit, external tools can consume it more easily. It can become the entry point for code generators. Also, it's more difficult to deal with folders for a web app, you can't really pick a folder with a file input. It's actually an issue for me with https://github.com/GuillaumeSalles/lona-viewer. I kind of like the idea of just upload/drop a lona file on the "lona-viewer" to generate a full style guide with code examples.

[dennislaupman]

I Think we need te set a several steps:

1. Change the (NS)Document structure. Its now based on components and missing the workspace layer (Right?)?
2. We add a FIleWrapper functionality to save file bundles instead of a single file

Is this something we can provide in the nearby future? I think its a fundamental change in the structure.

[dabbott]

Related: #113

Component names are now unique within a workspace, and refer to one another by name. This addresses some of the brittleness @GuillaumeSalles mentioned around moving files.

I think in the future, there may be nested/connect workspaces, and component names won't have to be unique between workspaces (think Swift modules)

I'm still 👍 for .lona wrapper thingy, and this is a step in that direction

[dabbott]

Some of the UI improvements (e.g. the landing screen) and features (lona.json) workspace indicator solve a lot of this I think. I don't think we need a wrapper anymore.