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

Support non-checked-in files #25

Open
conartist6 opened this issue Jul 6, 2021 · 2 comments
Open

Support non-checked-in files #25

conartist6 opened this issue Jul 6, 2021 · 2 comments

Comments

@conartist6
Copy link
Collaborator

Currently macrome assumes that all generated files are under version control. It should also be possible to do in-place building of files that are not under VCS. To implement this we will need to subscribe to some set of non-vcs changes and subscribe to them with defer instead of drop when the vsc_lock_held state is present. The main question is how we'll target each subscription. Currently watchman isn't given the targeting criteria which means there's no way to make the distinction at that level.

It seems to me that it will be appropriate to make the distinction between VCS and non-VCS generated assets at the generator level, i.e. allow generators to specify whether to drop or defer with regard to the vcs lock. The problem with this is that we currently only have one subscription, so we can't take advantage of that kind of power at a more granular level.

@conartist6
Copy link
Collaborator Author

So let's game this out: is it possible for each generator to have its own subscription?

Let's imagine a ts-generator that turns *.ts into *.js. Let's say we have a second generator, index-generator which generates certain index.js files. In general the inputs to the ts generator may or may not be generated files, and we wish to avoid bouncing behavior, as in this example:

[routes/index.ts] => routes/index.js
[routes/foo.ts] => routes/index.ts => routes/index.js

Note that routes/index.js must be generated twice here. It should be possible to use changeset logic to avoid this though, simply by choosing not to treat routes/index.ts as a changeset root since it has the @generated header.

@conartist6
Copy link
Collaborator Author

I think this can be supported using just two subscriptions: the current subscription to all files that drops vcs changes, and a new subscription to files which match paths defined by non-vcs generators which will defer changes made with a vcs lock present and drop everything else.

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

1 participant