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

Do not rewrite files when content did not change #8

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

rogeliog
Copy link

@rogeliog rogeliog commented Nov 28, 2017

First of all thanks for all the great work on this package,👏 it has been super useful!

I know that there is no open issue for this, so feel free to close this PR if this does not go with the direction of the project.

TL;DR

Don't write a new version of the .css.flow file if the contents did not change.

The problem

Every time that a file is changed our git repo gets dirty, making it hard to do

❯ git status
On branch my-banrch
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   src/components/Component1/styles.css.flow
	modified:   src/components/Component2/styles.css.flow
❯ git diff
diff --git a/src/components/Component1/styles.css.flow b/src/components/Component1/styles.css.flow
index 9c8e505..e69de29 100644
--- a/src/components/Component1/styles.css.flow
+++ b/src/components/Component1/styles.css.flow
@@ -1,9 +0,0 @@
-// @flow
-/* This file is automatically generated by css-modules-flow-types */
-declare module.exports: {|
-  +'class1': string;
-  +'class2': string;
-  +'class3': string;
-|};

diff --git a/src/components/Component2/styles.css.flow b/src/components/Component2/styles.css.flow
index 9c8e505..e69de29 100644
--- a/src/components/Component2/styles.css.flow
+++ b/src/components/Component2/styles.css.flow
@@ -1,9 +0,0 @@
-// @flow
-/* This file is automatically generated by css-modules-flow-types */
-declare module.exports: {|
-  +'class1': string;
-  +'class2': string;
-  +'class3': string;
-|};

@skovhus
Copy link
Owner

skovhus commented Nov 28, 2017

Thanks for contributing! Makes sense not to write file more than nessesary, but I don't see why your git repo gets dirty. It is simply touching the file.

@rogeliog
Copy link
Author

rogeliog commented Nov 29, 2017

🤦‍♂️ sorry, I forgot to add that to the description, my bad...

I still don't understand why it is taking so long to write to do the write, but here is what I have found.

My primitive benchmarking

I added a really primitive benchmarking, in my local setup

const start = +new Date();
fs.writeFile(outputPath, printFlowDefinition(tokens), {}, function() {
   console.log(+new Date() - start);
});

And this gives me values that range from 1ms to 2000ms... I wonder if it because there are too many
writeFile happening at the same time.

Info about the project

Node version: 8.6.0
webpack version: 1.13.0
Number of css files: 196

@rogeliog
Copy link
Author

Further investigation

It seems that typings-for-css-modules-loader is also just writing to file it the contents changed https://github.com/Jimdo/typings-for-css-modules-loader/blob/master/src/persist.js

@skovhus
Copy link
Owner

skovhus commented Nov 29, 2017

sorry, I forgot to add that to the description, my bad...

Still missing it seems. : ) I would like to understand why writing/touching a file is a problem on your system. It should not cause any unstated files in git.

Are you checking in the .css.flow files?

Performance slow down is the reason why I'm not reading the file. IO is expensive here. Especially inside a webpack loader.

@skovhus
Copy link
Owner

skovhus commented Nov 29, 2017

In the diffs shown here it look like the file content were removed... or am I missing something?

@rogeliog
Copy link
Author

Yes I'm checking in the .css.flow files, I'm working in a minimal repro case... I'll post it soon

@rogeliog
Copy link
Author

rogeliog commented Nov 29, 2017

Here is a minimal repro case for this issue ttps://github.com/rogeliog/fs-write-weird-issue

I don't know exactly why it happens, but think it has to do with how fs.writeFile works... in that repo I have a script that continuously writes to 100 files to disk.

I wonder if we should use fs.writeFileSync instead(which is what typings-for-css-modules-loader is using)

See https://github.com/rogeliog/fs-write-weird-issue for more details about this gif
repro-fs-write

@rogeliog
Copy link
Author

rogeliog commented Dec 8, 2017

Any thoughts?

@skovhus
Copy link
Owner

skovhus commented Dec 8, 2017

@rogeliog sorry I've been a bit busy. It seems like this is an issue on some machines... Wondering a bit why I haven't seen the issue before.

I wonder if we should use fs.writeFileSync instead(which is what typings-for-css-modules-loader is using)

Not sure if that will slow down webpack a lot. But please give it a try if you have time.

Can you see how much reading and writing the file affect webpack performance? Like you touch a .css file and see how long a rebuild takes.

@skovhus
Copy link
Owner

skovhus commented Dec 8, 2017

Thanks for the reproducible repo!

@skovhus skovhus self-requested a review December 10, 2017 00:22
@silvenon
Copy link

To me this seems like a good idea in general (performance-wise), regardless of the bug.

@silvenon
Copy link

silvenon commented Jan 6, 2019

How about using a local cache to store file content based on this.resourcePath? That way you can check contents without IO.

@skovhus
Copy link
Owner

skovhus commented May 27, 2019

How about using a local cache to store file content based on this.resourcePath? That way you can check contents without IO.

Good idea. 👍

@skovhus
Copy link
Owner

skovhus commented May 29, 2020

@silvenon @rogeliog not sure if you are still using this project?

I’m not actively using it anymore, but I’m open for a revamp of this PR.

@silvenon
Copy link

I'm not using Flow nor CSS Modules anymore, so not invested 🤷

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

Successfully merging this pull request may close these issues.

3 participants