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

[Feature] Place non-code digital assets in their own repo #48

Closed
shahankhatch opened this issue Oct 6, 2021 · 6 comments
Closed

[Feature] Place non-code digital assets in their own repo #48

shahankhatch opened this issue Oct 6, 2021 · 6 comments
Assignees
Labels
enhancement New feature or request

Comments

@shahankhatch
Copy link

Feature Description

Currently, non-code assets (e.g., SVG files, logos, fonts) are sprinkled across projects. E.g., the landing page includes the digital assets, while the delegate page references an S3 bucket (managed by a different team).

In order to establish improved control over our digital assets, place all non-code digital assets in their own repo and version the repo.

This will allow more stable development, testing, and deployment as we produce releases. Products that rely on these assets can then be upgraded at their corresponding pace.

In addition to this repo, this issue also affects the landing page repo.
https://github.com/bitdao-io/bitdao-interface

@octavioamu
Copy link
Contributor

I was thinking on this and I believe will add a lot of friction for development, using tools like https://www.npmjs.com/package/s3-folder-upload to sync the new assets to s3 on deploy time seems a better approach, even we can have setup on env's for staging and production.

@shahankhatch
Copy link
Author

The problem with deploying the assets directly to S3 is that the version of asset can change without the front end being ready for it (this happened during the landing page's development). Trying to version something on S3, such as by including version numbers in the naming conventions may require hardcoding that into front ends.

Essentially, by placing the asset into its own repo, then downstream consumers of the assets will obtain a specific version, will build their static page, and they themselves are deployed to S3 (and will carry the assets with them). Note that the S3 deployment of static websites is the standard approach we're taking.

Does that help to clarify?

@shahankhatch
Copy link
Author

Relatedly, we don't benefit from deploying the svg assets to S3 as we shouldn't be serving them directly to consumers. They end up on S3 as part of the static page build and deploy pipeline.

@octavioamu
Copy link
Contributor

octavioamu commented Oct 6, 2021

Mmm not sure I get 100% but what I use to do have 2 node commands one for local that serves images from localhost, in that way I can change images and add remove them.
Then the build command, that will do minification transform js and scss to css optimize images and hash all the files change the routes names of the files to mach the hashed ones and the upload all that files to a S3.

the hashing part and the build changes are handled in our case by react-scripts https://create-react-app.dev/docs/production-build so we don't need to manually change the hashes on each file.

@shahankhatch
Copy link
Author

Sounds like a better approach. Thanks for explaining.

@octavioamu
Copy link
Contributor

Closing as solved on #76

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

No branches or pull requests

2 participants