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

CLI: Option to skip file output if the same file already exists #6445

Open
natew opened this Issue Oct 8, 2017 · 10 comments

Comments

Projects
None yet
5 participants
@natew

natew commented Oct 8, 2017

Consider this a small feature request, or perhaps even something solvable in shell (though I know not how).

Basically, when doing an --out-dir with the CLI, it would be helpful to have a flag --skip-write-if-same. Reason being, if you have watchers running like webpack, it will get pretty frustrated by all the file writes as you run watchers.

I figure a PR wouldn't be too tricky to do, so if people think this is a good idea I could give it a go.

@babel-bot

This comment has been minimized.

Show comment
Hide comment
@babel-bot

babel-bot Oct 8, 2017

Collaborator

Hey @natew! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

Collaborator

babel-bot commented Oct 8, 2017

Hey @natew! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

@xtuc

This comment has been minimized.

Show comment
Hide comment
@xtuc

xtuc Oct 9, 2017

Member

I think this should actually be the default.
There is no reason to re-compile if the source file hasn't changed but there might be a few edge cases I don't have in mind currently.

Member

xtuc commented Oct 9, 2017

I think this should actually be the default.
There is no reason to re-compile if the source file hasn't changed but there might be a few edge cases I don't have in mind currently.

@loganfsmyth

This comment has been minimized.

Show comment
Hide comment
@loganfsmyth

loganfsmyth Oct 9, 2017

Member

Interesting idea, I guess that would be relatively easily to do. I'm up for accepting a PR for this I think.

@xtuc I don't think we can avoid recompiling at the moment since we can't easily know if something changed, but we can definitely recompile and then just skip writing to disk if the content is already there.

Member

loganfsmyth commented Oct 9, 2017

Interesting idea, I guess that would be relatively easily to do. I'm up for accepting a PR for this I think.

@xtuc I don't think we can avoid recompiling at the moment since we can't easily know if something changed, but we can definitely recompile and then just skip writing to disk if the content is already there.

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Oct 9, 2017

Member

The edge case is that the source is the same, but you changed your babelrc/node_modules and babel version(s) unless this is only during "watch"?

Member

hzoo commented Oct 9, 2017

The edge case is that the source is the same, but you changed your babelrc/node_modules and babel version(s) unless this is only during "watch"?

@xtuc

This comment has been minimized.

Show comment
Hide comment
@xtuc

xtuc Oct 9, 2017

Member

Sorry, I wasn't clear, I meant to avoid Babel writing a file with the same content which triggers a build in some watcher.

On the other hand we could store hashes to detect if a file has changed in Babel's input.

Member

xtuc commented Oct 9, 2017

Sorry, I wasn't clear, I meant to avoid Babel writing a file with the same content which triggers a build in some watcher.

On the other hand we could store hashes to detect if a file has changed in Babel's input.

@loganfsmyth

This comment has been minimized.

Show comment
Hide comment
@loganfsmyth

loganfsmyth Oct 9, 2017

Member

Yeah, storing hashes and such is where things start getting complicated. I have idea for that hopefully for 7.x, but it seems beyond the scope of what this is asking for.

Member

loganfsmyth commented Oct 9, 2017

Yeah, storing hashes and such is where things start getting complicated. I have idea for that hopefully for 7.x, but it seems beyond the scope of what this is asking for.

@xtuc

This comment has been minimized.

Show comment
Hide comment
@xtuc

xtuc Oct 9, 2017

Member

Yes, but as @hzoo said, a checksum of the content of the file in input won't suffice, it's not that easy.

About the output, it's simpler. I would compare the emited string from Babel with the current content of the file before writing in it.

Some watchers use the last modification date of the file; we could write the file with the exact same date but it doesn't make so much sense to me.

Member

xtuc commented Oct 9, 2017

Yes, but as @hzoo said, a checksum of the content of the file in input won't suffice, it's not that easy.

About the output, it's simpler. I would compare the emited string from Babel with the current content of the file before writing in it.

Some watchers use the last modification date of the file; we could write the file with the exact same date but it doesn't make so much sense to me.

@loganfsmyth

This comment has been minimized.

Show comment
Hide comment
@loganfsmyth

loganfsmyth Oct 9, 2017

Member

Agreed.

Member

loganfsmyth commented Oct 9, 2017

Agreed.

@natew

This comment has been minimized.

Show comment
Hide comment
@natew

natew Nov 11, 2017

Actually, there's a much simpler option that would actually solve my use case at least.

--watch-incoming

Basically: Starts a watch but doesn't compile anything until it sees a new change. That would let me then use babel-changed to do an initial compile (or just run a full compile way less often), and then I could run babel --watch-incoming without it re-building everything.

Currently working in a mono-repo that is growing, and starting to feel the pain. With 3 different compile targets * 26 packages, it starts to get a bit painful.

If this sounds appealing I'd happily send PR, seems like it should be fairly simple.

natew commented Nov 11, 2017

Actually, there's a much simpler option that would actually solve my use case at least.

--watch-incoming

Basically: Starts a watch but doesn't compile anything until it sees a new change. That would let me then use babel-changed to do an initial compile (or just run a full compile way less often), and then I could run babel --watch-incoming without it re-building everything.

Currently working in a mono-repo that is growing, and starting to feel the pain. With 3 different compile targets * 26 packages, it starts to get a bit painful.

If this sounds appealing I'd happily send PR, seems like it should be fairly simple.

@natew

This comment has been minimized.

Show comment
Hide comment
@natew

natew Nov 17, 2017

Holy crap this already exists (re: last comment)... --skip-initial-build

natew commented Nov 17, 2017

Holy crap this already exists (re: last comment)... --skip-initial-build

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment