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

Remove shared directory by default or w/ flag #15

Open
djfarrelly opened this issue Jan 20, 2019 · 2 comments
Open

Remove shared directory by default or w/ flag #15

djfarrelly opened this issue Jan 20, 2019 · 2 comments
Labels
feature priority Priority tasks

Comments

@djfarrelly
Copy link
Contributor

Purpose

Inspired by the discussion in this PR, we can remove the shared directory prefix to allow for cleaner manifests and easier usage. This would make the @bufferapp/static-assets library simpler and custom solutions to be cleaner as well.

Idea

Given a generated manifest:

{
  "public/js/bundle.js": "https://static.buffer.com/my-app/public/js/bundle.123456789.js"
}

It would become:

{
  "js/bundle.js": "https://static.buffer.com/my-app/js/bundle.123456789.js"
}

Since most apps are never referencing ./public in their code, it makes sense to remove it, potentially by default. To do this we could:

  • Automatically remove the word public as a prefix directory
  • Check all file globs and remove any common base directory that is shared by all
  • Change the structure of the globs to be simpler or allow for a directory prefix input, ex. `buffer-static-upload -prefix public -files 'js/.js,css/.css'
@philippemiguet
Copy link

@djfarrelly, one potential issue with this is, if someone uploads 2 files with the same name, one from the root dire ./ and the other from ./public, it will result in conflicting keys. That's a edge case those and shouldn't happen.

Usually the files in the root dir are gulp generated files. We could share a good practice to generate those files in a specific directory ./build for instance, and never upload files from the root directory :)

@djfarrelly
Copy link
Contributor Author

Good call @philippemiguet, that will likely be another check we should add in a function like EnsureUniqueKeys that throws and error if there are duplicates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature priority Priority tasks
Projects
None yet
Development

No branches or pull requests

2 participants