Enhancement: Add support for allowing multiple asset locations - monorepo #435

New Issue

Closed

opened 2026-10-05 02:47:18 +02:00 by adam · 11 comments

adam commented 2026-10-05 02:47:18 +02:00

Owner

Copy link

Copy source

Discussed in https://github.com/estruyf/vscode-front-matter/discussions/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.

### Discussed in https://github.com/estruyf/vscode-front-matter/discussions/542 <div type='discussions-op-text'> ^{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. </div> <!-- github-sync-id:1638922394 -->

adam closed this issue 2026-10-05 02:47:18 +02:00

adam commented 2026-10-05 02:47:19 +02:00

Author

Owner

Copy link

Copy source

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.

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. <!-- github-comment-id:1482754244 -->

adam commented 2026-10-05 02:47:20 +02:00

Author

Owner

Copy link

Copy source

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

Thinking about a new `assetFolder` property on the page folders setting:  <!-- github-comment-id:1483913251 -->

adam commented 2026-10-05 02:47:21 +02:00

Author

Owner

Copy link

Copy source

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?

> 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? <!-- github-comment-id:1483916663 -->

adam commented 2026-10-05 02:47:21 +02:00

Author

Owner

Copy link

Copy source

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 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: ```json { "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" } ] } ``` <!-- github-comment-id:1490147959 -->

adam commented 2026-10-05 02:47:22 +02:00

Author

Owner

Copy link

Copy source

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?

> 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: > > ```json > { > "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? <!-- github-comment-id:1490345568 -->

adam commented 2026-10-05 02:47:23 +02:00

Author

Owner

Copy link

Copy source

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

Using Mindnode for this

> OK, I'm wondering what software did you use to create that diagram? Using **Mindnode** for this <!-- github-comment-id:1490347113 -->

adam commented 2026-10-05 02:47:23 +02:00

Author

Owner

Copy link

Copy source

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.

> 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: > > ```json > { > "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. <!-- github-comment-id:1490428656 -->

adam commented 2026-10-05 02:47:24 +02:00

Author

Owner

Copy link

Copy source

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.

https://user-images.githubusercontent.com/2900833/228933325-c524dd55-ae9e-454f-a7b5-89c9a3d52ac4.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"
    }
  }]
}

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. https://user-images.githubusercontent.com/2900833/228933325-c524dd55-ae9e-454f-a7b5-89c9a3d52ac4.mov ```json { "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" } }] } ``` <!-- github-comment-id:1490759988 -->

adam commented 2026-10-05 02:47:25 +02:00

Author

Owner

Copy link

Copy source

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.

> 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. > > ```json > { > "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. <!-- github-comment-id:1490908538 -->

adam commented 2026-10-05 02:47:26 +02:00

Author

Owner

Copy link

Copy source

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.

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. <!-- github-comment-id:1491387108 -->

adam commented 2026-10-05 02:47:27 +02:00

Author

Owner

Copy link

Copy source

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

It has been pushed to the latest beta version and can be tested by adding a similar configuration as shown above. <!-- github-comment-id:1491471318 -->

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

beta

dependabot/npm_and_yarn/js-yaml-4.3.1

dependabot/npm_and_yarn/multi-7958ac4c45

dependabot/npm_and_yarn/postcss-8.5.25

dependabot/npm_and_yarn/multi-670d462a53

dependabot/npm_and_yarn/http-proxy-middleware-2.0.10

dependabot/npm_and_yarn/shell-quote-1.10.0

dependabot/npm_and_yarn/websocket-driver-0.7.5

dependabot/npm_and_yarn/multi-6aaed2ab8e

copilot/validate-issue-1043

dependabot/npm_and_yarn/multi-84120a5570

dependabot/npm_and_yarn/launch-editor-2.14.1

dependabot/npm_and_yarn/multi-9dd3b9b346

estruyf/smart-file-rename

copilot/fix-unwanted-auto-update-publish-date

copilot/fix-content-view-sorting-issue

copilot/fix-virtual-workspace-folder-selection

copilot/fix-937

copilot/fix-965

copilot/fix-958

copilot/fix-950

copilot/fix-932

copilot-integration

hotfix/10.2.1

issue/816

issue/671

i18n

azure-translator

issue/747

issue/673

poc/content-tagging

combobox

v10.13.0

v10.12.0

v10.11.0

v10.10.1

v10.10.0

v10.9.0

v10.8.0

v10.7.0

v10.6.0

v10.5.1

v10.5.0

v10.4.1

v10.4.0

v10.3.0

v10.2.1

v10.2.0

v10.1.0

v10.0.2

v10.0.1

v10.0.0

v9.4.0

v9.3.1

v9.3.0

v9.2.0

v9.1.0

v9.0.0

v8.4.0

v8.3.0

v8.2.0

v8.1.2

v8.1.1

v8.1.0

v8.0.1

v8.0.0

v7.3.4

v7.3.3

v7.3.2

v7.3.1

v7.3.0

v7.2.0

v7.1.2

v7.1.1

v7.1.0

v7.0.0

v6.1.1

v6.1.0

v6.0.0

v5.10.0

v5.9.0

v5.8.0

v5.7.0

v5.6.0

v5.5.0

v5.4.0

v5.3.1

v5.3.0

v5.2.0

v5.1.1

v5.1.0

v5.0.0

4.0.1

4.0.0

3.1.0

v3.0.2

v3.0.1

v3.0.0

v2.5.1

v2.5.0

v2.4.1

v2.4.0

v2.3.0

v2.2.0

v2.1.0

v2.0.1

v2.0.0

v1.18.0

v1.17.1

v1.17.0

v1.16.1

v1.16.0

v1.15.1

v1.15.0

Labels

No items

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

adam (Adam Wojcieszonek)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/vscode-front-matter#435