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

--noClean support for build #746

Open
gaetansnl opened this issue Jun 12, 2020 · 5 comments
Open

--noClean support for build #746

gaetansnl opened this issue Jun 12, 2020 · 5 comments
Labels
kind: discussion Discussion on changes to make kind: feature New feature or request problem: stale Issue has not been responded to in some time scope: integration Related to an integration, not necessarily to core (but could influence core)

Comments

@gaetansnl
Copy link

Current Behavior

--noClean not working for tsdx build

Desired Behavior

--noClean working for tsdx build

Suggested Solution

Add --noClean option for tsdx build

Who does this impact? Who is this for?

Impact us because be use a different system for watching, we don't use tsdx watch

Describe alternatives you've considered

We are downgrading to a version before v0.10.0

@agilgur5
Copy link
Collaborator

agilgur5 commented Jun 12, 2020

--noClean exists as a workaround for parallel builds per #578 (comment) and related issues mentioned there. It's not actually a feature we want to support long-term as it is quite suboptimal and risks stale cache issues as is mentioned in that issue.

I don't know what kind of watch system you're using, but I would check if that has a better clean option first. Repeated tsdx build is also much less efficient than watch, so I don't think we really want to encourage or allow that unless it's absolutely necessary.

I think this would need a lot more information on use-case to be considered.

@agilgur5 agilgur5 added kind: discussion Discussion on changes to make kind: feature New feature or request scope: integration Related to an integration, not necessarily to core (but could influence core) labels Jun 12, 2020
@gaetansnl
Copy link
Author

gaetansnl commented Jun 13, 2020

I use monorepo with lot of packages. The build happens in the cluster, not on my local machine. When I edit something on my machine the file is copied on N servers using this file. And these servers rebuild the package with tsdx build.

I saw people having problems with watching monorepo #275 (comment) that's why I do it this way : /

@agilgur5
Copy link
Collaborator

So the clusters are constantly running a watch process and rebuilding other things that depend on the package when you make an edit?
I'm not totally sure why the servers wouldn't just run tsdx watch instead then if they're already running watchers.

I saw people having problems with watching monorepo #275 (comment) that's why I do it this way : /

That comment seems to point to monorepos where you have a TSDX package that depends on another package in the monorepo (often it's the other way around, unless you have libraries built on top of each other). If you have that problem, a feature request for the ability to customize Rollup's watchOptions might make sense.

@gaetansnl
Copy link
Author

Yes if there is a way to build a DAG of packages in a monorepo, using tsdx watch, it would work.
But i'm not sure changing the watch options would solve that ? It require that the packages are built in the correct order, following the dependencies in the DAG.

The great thing with tsdx build is that I can build the package in any order I want and I have more control.

@agilgur5
Copy link
Collaborator

agilgur5 commented Jul 7, 2020

Yes if there is a way to build a DAG of packages in a monorepo, using tsdx watch, it would work.

Isn't that exactly what lerna run watch --stream would do?

That might not work for watch though per the other comments in #275 (comment), though that exact example existing in the Lerna docs suggests otherwise. Idk, I've never run a lerna monorepo and Jared never quite fixed #122 as he said he would. (The eventual plan is to have TSDX itself be a monorepo for #634 and maybe #635 and others, so maybe lerna will be dogfooded at that point).

But i'm not sure changing the watch options would solve that ?

The comment you specifically linked to, #275 (comment), which I was responding to, suggests watching node_modules for symlink updates is what's necessary to support that workflow. You're not using a DAG if you're using --parallel per that comment.

It's not clear to me if you're using Lerna as your watcher or if this is a Lerna monorepo or what.

@agilgur5 agilgur5 added the problem: stale Issue has not been responded to in some time label Oct 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: discussion Discussion on changes to make kind: feature New feature or request problem: stale Issue has not been responded to in some time scope: integration Related to an integration, not necessarily to core (but could influence core)
Projects
None yet
Development

No branches or pull requests

2 participants