Wireit Configuration File

[mihar-22]

Would be super clean if we could remove the clutter from the package.json file to a Wireit configuration file. It currently spans 200 lines for my player build right now which has a lot of steps and artificats.

wireit.json is short and sweet IMO.

[aomarks]

Thanks for filing! I'm a little torn on this.

1. I can see the organizational appeal of a separate file for a more complex build graph.

   On the other hand, one of our major goals is to meld with npm; to feel more like an extension to npm's scripts feature, instead of an entirely separate build system. In this regard, the package.json file feels like the right place for your script's build graph to live — right next to the scripts themselves.

   Going even further, one day we'd love to see npm itself supporting defining your config directly in the scripts field, like this (we're planning to start an npm RFC to propose something along these lines soon!):

   {
     "scripts": {
       "test": {
         "command": "wtr",
         "dependencies": {
           "build"
         }
       }
     }
   }

2. It would have the advantage of letting us register a JSON schema for that filename for VSCode.

   @rictic is working on a VSCode extension that will give us validation and other helpful features inside the package.json, so we will get this benefit regardless (at least for VSCode users).

3. It would have the advantage of allowing you to exclude those bytes from the npm package.

   The whitespace you get in JSON formatting can make 200 lines look like a lot, but it's probably not something that a user would ever feel, especially given that npm packages are compressed. For example, I just compared the gzipped size of a package.json file with and without 200-lines of wireit config, and the difference was around 500 bytes.

So, for right now I'm thinking we should probably stick with the package.json approach and see how things turn out. Keeping an open mind and early days, though, so feel free to comment here as you get more experience using it!

[brendankenny]

Very excited to try out wireit!

Big +1 for configuration outside of package.json. I definitely understand the simpler story the current approach helps self-explain as an extension of npm, but it also means it inherits all the the usability issues of npm scripts (supporting at least json5 (or equivalent) would also be a huge plus to allow comments and single-quoted strings to side step some of the quote-escaping ugliness). Plus as a package.json grows, it's increasingly annoying to find a particular block in there, vs finding it in the file system :)

When/if you do consider it, it could be an explicit option on top of a default package.json approach, either through a flag or even "wireit": "./path/to/config.json" in package.json (always nice to get config files out of the root directory).

[luxaritas]

This seems like something that would be good as an option - many tools allow you to provide configuration either in a dedicated file or package.json. Depending on the situation, sometimes I find it valuable to have configuration explicitly separated out, but it can also be nice to limit the amount of files that are floating around in the root of a package.

[Chriscbr]

I'd also be interested in this. 👍

One of our major goals is to meld with npm; to feel more like an extension to npm's scripts feature, instead of an entirely separate build system.

Could you give examples of the kinds of features in wireit today that are specifically depend on or align most with npm? The reason I ask is I wonder if the general implementation / data model could be reused if say I had a collection of tasks in a DAG for my Python software project, or my Ruby project, or etc. The main difference I'd see is I'd have to invoke some tasks some other way, like $ wireit <task name> etc. Separating the configuration file out would be one piece of that feature.

All that said, I totally respect the choice to focus on just making this opinionated and optimized for one kind of language ecosystem. 😄 This is a pretty cool tool.

[gunta]

Going even further, one day we'd love to see npm itself supporting defining your config directly in the scripts field, like this (we're planning to start an npm RFC to propose something along these lines soon!):

This would be 100% amazing 👍

[ScottAwesome]

My sincerest question:

why not use the config key in package.json ? I thought thats what it was for, tools and the like.

[Muromi-Rikka]

My sincerest question:

why not use the config key in package.json ? I thought thats what it was for, tools and the like.

@ScottAwesome package.json is too long

[scottrippey]

I always love tools that give me a choice between .json and .js ... if my configuration gets complex, or needs to inherit a base config, then I love it when I get the full power of JavaScript and Node to make things happen!

[elado]

+1 on this.

I'm trying to integrate wireit in a large monorepo (~30 packages with many dependencies). Changing all the scripts to wireit and the configuration is quite a lot. I don't like "marrying" a tool in such an obtrusive way.

I'd rather keep package.jsons untouched, and have a package manager (e.g. yarn) plugin that will execute wireit before a script. I implemented it with nx integration but wireit provides important features that nx doesn't, so I'm considering a migration.

My proposal is either a per-package wireit.json or even better, a root wireit.json file.

[aomarks]

I'm trying to integrate wireit in a large monorepo (~30 packages with many dependencies). Changing all the scripts to wireit and the configuration is quite a lot. I don't like "marrying" a tool in such an obtrusive way.

Interesting! I agree about not wanting to "marry" the tool, but I actually see the current approach as an advantage, not a disadvantage, in this respect. The current approach means that individual scripts can opt-in to using wireit, and the tool that launches the script doesn't need to know anything about it. You can use wireit with npm, yarn, pnpm, even lerna or other monorepo-managing tools. So you don't have to change anything about your workflow or learn any new commands. Whereas the tools that require you to replace standard tools like npm, yarn, pnpm with their specialized cli or the whole system breaks down feel more like a marriage, to me.

[elado]

The current approach means that individual scripts can opt-in to using wireit, and the tool that launches the script doesn't need to know anything about it. [...] So you don't have to change anything about your workflow or learn any new commands

This is exactly what I implemented in a yarn plugin.

I can still cd to any package and yarn build/yarn start and it will first run nx to ensure the dependencies are built, then proceed with the original script.
So.. best of both worlds :)

[leadoflife]

We would prefer a JS module file over JSON to allow us to build up the configuration. We have a LOT of config duplication in our monorepo, especially for tasks that use the same input file patterns. If this were a JS file with a JSON export declaration, we could execute any JS necessary to build up and return the configuration.