Enhancement: Add support for allowing multiple asset locations - monorepo

[estruyf]

Discussed in #542

^{Originally posted by louiss0 March 18, 2023}
I have decided to talk about this as a feature idea because. I didn't think of the problem as an issue as in bug. But what I'm going to talk about is a restriction. As of today you are only allowed to use one assets folder. This is not good for people like me who use mono-repos.

Right now this is all I can do. If can could specify multiple files they would look like this.

This is what I want to do. The benefit of this is that the key could be the name of the place where each asset is displayed. The value is the folder to use. This means that pictures and where they come from can be specified in a mono-repo. even outside of a mono-repo developers can organize where each set of images are in a folder.

[louiss0]

I wish I could do more to help but I don't know much about this extension. I hope you remember that the key is supposed to be used to tell Frontmatter CMS what folder to put the assets in.

[estruyf]

Thinking about a new assetFolder property on the page folders setting:

[louiss0]

Thinking about a new assetFolder property on the page folders setting:

I'm sorry but the pageFolders thing is throwing me off. I think this is an attempt to make the folders configurtion more modular instead of global. Which works. If you are thinking about making a modular architecture this means that each page folder should be a new context. My suggestion would have made everything be a part of the global scope. I think I'll need a bigger comment to express what I mean. But the thing is how will this affect Frontmatter CMS as a whole?

[estruyf]

I understand you @louiss0, but it needs to fit into the whole system. The setting you propose would work nicely when using a mono-repository, but it won't work or is a lot trickier when using a single project and wanting to specify two asset locations. Which I believe might also be an option on sites with various types of content.

That is why I want to make a change that would work for both a single and a mono-repo project. I have listed the options which can be done.

In my opinion, option 5 is the best of all.

It would look as follows:

{
  "frontMatter.content.publicFolder": [
    {
      "title": "blog-public",
      "path": "[[workspace]]/blog/public",
      "publicFolders": ["blog-page"]
    },
    {
      "title": "portfolio-public",
      "path": "[[workspace]]/portfolio/public",
      "publicFolders": ["portfolio-page"]
    }
  ],
  "frontMatter.content.pageFolders": [
    {
      "title": "blog-page",
      "path": "[[workspace]]/blog/content",
      "excludeSubdir": true
    },
    {
      "title": "portfolio-page",
      "path": "[[workspace]]/portfolio/content"
    }
  ]
}

[louiss0]

I understand you @louiss0, but it needs to fit into the whole system. The setting you propose would work nicely when using a mono-repository, but it won't work or is a lot trickier when using a single project and wanting to specify two asset locations. Which I believe might also be an option on sites with various types of content.

That is why I want to make a change that would work for both a single and a mono-repo project. I have listed the options which can be done.

In my opinion, option 5 is the best of all.

It would look as follows:

{
  "frontMatter.content.publicFolder": [
    {
      "title": "blog-public",
      "path": "[[workspace]]/blog/public",
      "publicFolders": ["blog-page"]
    },
    {
      "title": "portfolio-public",
      "path": "[[workspace]]/portfolio/public",
      "publicFolders": ["portfolio-page"]
    }
  ],
  "frontMatter.content.pageFolders": [
    {
      "title": "blog-page",
      "path": "[[workspace]]/blog/content",
      "excludeSubdir": true
    },
    {
      "title": "portfolio-page",
      "path": "[[workspace]]/portfolio/content"
    }
  ]
}

OK, I'm wondering what software did you use to create that diagram?

[estruyf]

OK, I'm wondering what software did you use to create that diagram?

Using Mindnode for this

[louiss0]

I understand you @louiss0, but it needs to fit into the whole system. The setting you propose would work nicely when using a mono-repository, but it won't work or is a lot trickier when using a single project and wanting to specify two asset locations. Which I believe might also be an option on sites with various types of content.

That is why I want to make a change that would work for both a single and a mono-repo project. I have listed the options which can be done.

In my opinion, option 5 is the best of all.

It would look as follows:

{
  "frontMatter.content.publicFolder": [
    {
      "title": "blog-public",
      "path": "[[workspace]]/blog/public",
      "publicFolders": ["blog-page"]
    },
    {
      "title": "portfolio-public",
      "path": "[[workspace]]/portfolio/public",
      "publicFolders": ["portfolio-page"]
    }
  ],
  "frontMatter.content.pageFolders": [
    {
      "title": "blog-page",
      "path": "[[workspace]]/blog/content",
      "excludeSubdir": true
    },
    {
      "title": "portfolio-page",
      "path": "[[workspace]]/portfolio/content"
    }
  ]
}

I think this code snippet represents the idea that different assets can map to different folders. This is ok but I think you meant pageFolders not publicFolder I'm wondering how it would be displayed in the UI. Would it be one folder containing multiple folders. What is the excludeSubdir thing about. Can you also tell me how the publicFolders key influences the UI.

[estruyf]

Have been trying option number 5 and 4. Option 5 is a huge change in architecture, but also leads to confusion on how to highlight the correct folder when you open a file.

Option 4 might be easier for users to understand and the implementation/configuration is pretty easy. The frontMatter.projects setting, allows you to override any of the global defined settings. So in your case, you can define the page folders and public/asset folders per project. Once that is done, on the dashboard and panel you'll be able two switch between the projects.

Screen.Recording.2023-03-30.at.20.40.17.mov

{
  "frontMatter.projects": [{
    "name": "eliostruyf.com",
    "default": true,
    "configuration": {
      "frontMatter.content.pageFolders": [
        {
          "title": "Blog posts",
          "path": "[[workspace]]/.frontmatter/content/posts"
        }
      ],
      "frontMatter.content.publicFolder": ".frontmatter/static/uploads"
    }
  }, {
    "name": "elio.dev",
    "configuration": {
      "frontMatter.content.pageFolders": [
        {
          "title": "Portfolio",
          "path": "[[workspace]]/.frontmatter/content/projects"
        }
      ],
      "frontMatter.content.publicFolder": ".frontmatter/static/social"
    }
  }]
}

[louiss0]

Have been trying option number 5 and 4. Option 5 is a huge change in architecture, but also leads to confusion on how to highlight the correct folder when you open a file.

Option 4 might be easier for users to understand and the implementation/configuration is pretty easy. The frontMatter.projects setting, allows you to override any of the global defined settings. So in your case, you can define the page folders and public/asset folders per project. Once that is done, on the dashboard and panel you'll be able two switch between the projects.

{
  "frontMatter.projects": [{
    "name": "eliostruyf.com",
    "default": true,
    "configuration": {
      "frontMatter.content.pageFolders": [
        {
          "title": "Blog posts",
          "path": "[[workspace]]/.frontmatter/content/posts"
        }
      ],
      "frontMatter.content.publicFolder": ".frontmatter/static/uploads"
    }
  }, {
    "name": "elio.dev",
    "configuration": {
      "frontMatter.content.pageFolders": [
        {
          "title": "Portfolio",
          "path": "[[workspace]]/.frontmatter/content/projects"
        }
      ],
      "frontMatter.content.publicFolder": ".frontmatter/static/social"
    }
  }]
}

How have you been testing this out? You can use the Frontmatter CMS repo to test things out. I think I like Option 4. I'm biased because I'm new to this library. But I think this option allows devs to be very explicit about which project each assets are associated with. I also think this removes the boilerplate introduced by Option 5. I don't know how dangerous it is to do Option 4 because I don't know how long it has been around. But If this project is young I'd suggest you go for Option 4.

I know the architectural changes are not easy but they are good if they simplify things or add much-needed flexibility.

[estruyf]

I have been testing it out against my blog and some of the sample sites: https://github.com/FrontMatter/project-samples

Option 4 will be the easiest to understand and allows the most flexibility for future implementations.

The implementation isn't that "dangerous"; without any projects defined, it will be as it is right now.

[estruyf]

It has been pushed to the latest beta version and can be tested by adding a similar configuration as shown above.