Let people choose to only build specific packages

[emmatown]

No description provided.

[tunnckoCore]

What's the desired flag/option name? filter and short -f?

Btw, also caching the built files would be cool too. This way it wouldn't even build/touch them if src or the preconstruct config isn't changed. I'm doing this in the jest-runner-rollup and it's pretty great. I can freely run build all the time without carryingto filter.

[emmatown]

I'm mostly leaning towards not allowing this because I can't really see a use case for it because people should only ever do a build when they're publishing packages in which case you'll probably be building a lot of packages anyway and a slightly slower build won't really make a big difference. (and ideally the publishing would happen from CI where the bottleneck is more likely to be installing dependencies than running a build)

Btw, also caching the built files would be cool too. This way it wouldn't even build/touch them if src or the preconstruct config isn't changed. I'm doing this in the jest-runner-rollup and it's pretty great. I can freely run build all the time without carryingto filter.

Preconstruct probably won't do caching because caching Babel transformations is impossible to do perfectly correctly(e.g. plugins like babel-plugin-codegen) and for apps technically imperfect caching solution is sometimes a problem though it's generally fine but for packages it's very problematic because it means publishing broken packages.

[steve-taylor]

This is already a feature. Exclude packages you don't want preconstruct to know about in the root package.json's preconstruct.packages field, e.g.

{
  "name": "my-monorepo",
  "version": "1.0.0",
  "yarn": {
    "workspaces": {
      "apps/*",
      "libs/*"
    }
  },
  "preconstruct": {
    "packages": [
      "libs/*"
    ]
  }
}

Packages inside apps/ will be excluded.

[alecdwm]

@steve-taylor I think this issue is about building only one of the packages inside libs/*, not about excluding apps/* from preconstruct.
Same idea as this one. It would let people use turborepo to cache individual packages, meaning they don't have to rebuild the entire monorepo every time a single package has been changed.
Would be definitely be useful for speeding up CI builds.

[jrolfs]

I'm also pretty keen on this for the Turborepo use case @alecdwm mentioned. I'd be happy to help contribute here and test things out, as I'm currently using Preconstruct with Turborepo and had to disable most caching in order to get things to work reliably.