Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a "public" Directory for Non-Image Content in Base Template #243

Open
jmandel opened this issue Jan 29, 2024 · 3 comments
Open

Create a "public" Directory for Non-Image Content in Base Template #243

jmandel opened this issue Jan 29, 2024 · 3 comments
Labels
Approved Approved on tooling call enhancement New feature or request

Comments

@jmandel
Copy link
Contributor

jmandel commented Jan 29, 2024

Currently, non-image content is being placed in the "images" directory to ensure it is included at the root level of the build output. This practice is not semantically clear, as the "images" directory implies it should only contain image files. To improve clarity and organization, a new directory, tentatively named "public," should be created in the base template to hold non-image content.

This change would help developers better understand where to place their files and make the content structure more logical.

Acceptance Criteria:

  1. A new directory at input/public is supported in the base template.
  2. Non-image content placed in the "public" directory should be accessible at the root level of the build output.
  3. Documentation is updated to reflect this new directory and its intended use.
@costateixeira
Copy link
Collaborator

Related to HL7/fhir-ig-publisher#780

@lmckenzi lmckenzi transferred this issue from HL7/fhir-ig-publisher Feb 6, 2024
@lmckenzi lmckenzi added enhancement New feature or request Approved Approved on tooling call labels Feb 6, 2024
@lmckenzi
Copy link
Contributor

lmckenzi commented Feb 6, 2024

We will define input/assets which we think is a clearer name than 'public'. It will be handled the same as 'images'. It will be possible to have content in both folders and content of both will be propagated to output unchanged.

@jmandel
Copy link
Contributor Author

jmandel commented Feb 6, 2024

"assets" works fine, thanks! When supporting both images + assets I'd say it should be an error to have overlapping content like:

  • images/a
  • assets/a

Or

  • images/b/one
  • assets/b/two

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Approved Approved on tooling call enhancement New feature or request
Projects
Development

No branches or pull requests

3 participants