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

how about just compress once for one image/assets #130

Open
buddywang opened this issue May 22, 2024 · 9 comments
Open

how about just compress once for one image/assets #130

buddywang opened this issue May 22, 2024 · 9 comments

Comments

@buddywang
Copy link

What problem does this feature solve?

for now, every image will be compressed in every build, this is a bit repetitive and wasteful

What does the proposed API look like?

use a extra file to record which files has been compressed before, and there will no compression for those file in next build
we can use git client-side hook like pre-commit to check whether there has image not being compressed and we can compress them an update the record-file, and interrupt the commit and ask to add a new commit for new compressed file

the extra file can use the hash value of the compressed file to determine whether the file has been compressed

@buddywang
Copy link
Author

If the author agrees with the idea, I'd be happy to contribute😀

@ErKeLost
Copy link
Member

ErKeLost commented May 22, 2024

hi @buddywang Thank you for your use.

  1. At present, there is a cache module in the code, which will cache all the compressed images locally. If it is compressed for the first time, it will not continue to be compressed, but this module has not been released because it is not perfect because of its work.

  2. I think your idea is very interesting, but I don't know if it will involve some similar privacy issues, such as obtaining user git-related information (because I don't know the specific implementation). Another question is whether pre-commit is similar to api, because we can't guarantee that all users will install pre-commit.

Of course, if all the above problems can be solved correctly, pr is welcome, or if you like, you can continue to optimize the cache function.

@buddywang
Copy link
Author

hi, it just my initial thought, I'm going to study it and see how to implement it

  1. From your description, the original files will still be retained. Are the compressed files saved locally? Will they be submitted to the git repository? Can others use this cache? It doesn’t look like what I had in mind;

  2. about how can we do this, just like lint-staged, it can do something like that, git hook will exist when running git init. For projects that do not use git, we can provide some commands to complete the same work.

If I want to contribute, will it be based on the main branch?

@buddywang
Copy link
Author

@ErKeLost we can get git status like this
image

@ErKeLost
Copy link
Member

oh, I probably understand your idea. If the local cache is stored in node_modules, the cache cannot be shared in this case. We may be able to provide two cache modes, one local and one git,fock main branch. pr welcome !

@buddywang
Copy link
Author

👌

@buddywang
Copy link
Author

After some thinking, I decided it would be more appropriate to make a framework-agnostic tool. I decided to implement it in a new project, thanks to the inspiration of this project.🤔

@ErKeLost
Copy link
Member

Well, it is possible that it would be better to make a separate tool, thank you.

@buddywang
Copy link
Author

it already exists: @democrance/imagemin-lint-staged

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

No branches or pull requests

2 participants