wireit VS sso-wall-of-shame

npm workspaces plus Wireit works far better than Lerna, in my experience.

https://github.com/google/wireit

Wireit's ability to specify actual script dependencies, do caching (and on Github actions), and it's long-running service script support make it much more useful and comprehensive than Lerna.

I agree that this should be built into npm. There's an RRFC for it here: https://github.com/npm/rfcs/issues/706

I must admit I'm a bigger fan of the wireit[0] approach, the only pause I have is its a Google project, my temptation is to fork it. The code isn't terribly complex

My biggest complaint with NX is: lack of a sane API for plugins, and it has more overhead than I'd care for. For the amount of complexity that NX has, I'd rather use Rush[1] which gives you everything NX does. My only complaint with Rush is that its development is really slow going, they really need to focus up on Rush plugins (they're good, but still experimental, and I'd love to see them clean up how `autoinstalls` work to be more intutive)

I'm on the fence about turbo from Vercel

[0]: https://github.com/google/wireit

[1]: https://rushjs.io/

To further derail the conversation there's also https://github.com/google/wireit

There's also wireit made by Google which pairs well with Yarn/NPM workspaces

Google recently anounced wireit, a program that runs multiple NPM scripts that depend on one another. Combined with NPM Workspaces, it enables monorepo workflows that previously required tools like Yarn and Pnpm.

etc.

where a bunch of related projects live top-level in a repo. Each project has a packages folder that includes the core implementation, as well as demos, framework-specific adaptors, etc.

In each package's package.json, I have a series of commands (convert the TS to JS, make a bundle, deploy to Firebase, etc.). Each command can depend on another, either in the same project or anywhere else in the file hierarchy.

This provides two benefits:

1. Iterating across packages is faster, because I don't have to worry about making sure each package rebuilds in the right order if I make a change in a library.

2. Filesystem concerns are separated: rollup only needs to worry about bundling, and it only needs to bundle web-facing projects. The only tool my libraries need is tsc.

(Using TypeScript and Rollup together is kind of a pain in the ass because you have to fiddle with picking the right TS plugin and configuring it. This is also often the long pole on doing a Rollup version upgrade. Decoupling the two makes Rollup way simpler/easier/nicer to use, which makes wireit awesome even if you don't have multiple packages.)

Here's a snippet from one of my package.jsons. They basically all look like this. (start is complicated because of https://github.com/google/wireit/issues/33. When that's resolved, it will be as simple as the others.)

    "scripts": {

Hi HN!

I have been doing over month long of research in terms of figuring out the best way to manage a growing monorepo. We are trying to consolidate much of our frontend code base into a monorepo, managed by pnpm workspaces, to consolidate dependency management and take advantage of tool (as well as other code sharing benefits) of monorepos that are a good fit for us.

To that end, I'm looking to understand if anyone has used Bazel extensively for managing monorepos.

I want to understand how easy it is to configure Bazel, how easy it is to use Bazel, especially newer developers (particularly self discovery of the toolset), how easy it is to maintain it, and how much burden the tool has placed on developers. We really are looking for a tool that is largely self sufficient for the purpose.

Main features we care about:

- Maintainability: is it is to maintain (updates etc)

- Extensibility: how extensible is it? more importantly, how easily can it be extended?

- Built in watch mode that understands its dependency graph for each task, and can run them simultaneously

- Works with pnpm / npm workspaces natively

- Stream based output: e.g. if running multiple tasks it interleaves them appropriately, even better if they're labeled and color coded

- Dependency graph tracking. IE: if I run build for a package, it understands that it may have dependencies that need to be built first.

- Able to run tasks arbitrarily on a "per package" process, potentially

Now, after mentioning all that, I realize, by reading the docs, in theory Bazel supports all this and has lots of feature headroom for growing features over time which I like, however, I've read mixed things about it, but not all of the sources I've read so far are "up to date" (some articles about people adopting Bazel are years old now) and I wanted to get a more accurate picture of what is going on here.

Alternatively, I'm open minded to looking at a different set of tools

For context I've done alot of research and experimentation with the follow:

- nx[0]

- rush[1]

- wireit[2]

- turbo[3]

We've settled on, for now `wireit` in part because it has a really good watch mode feature that `nx` does not (nx doesn't have a built in watch mode for your task runner, it relies on the plugin / script to handle it, which was really problematic). However, wireit isn't extensible, and I'm not looking to have to manage sub task "phasing" with something like `gulp`. This was an issue with rushjs as well (but rushjs has its own challenges and opinions). While rush is starting to expose a direct `rush-sdk` API, its not really documented and I'm not sure about its stability or best way to go about making rush plugins. They also have a competing task runner called `heft` that I'm not sure about in the light of the `rush-sdk` and its use cases (if someone from the rush team sees this and can clarify about the long term vision and where they're at with it now, I'm all ears)

tl;dr: I've tried tons of tools, and Bazel seems to check all the boxes, but I'm afraid the complexity will kill us, since we don't have a dedicated tool engineer to oversee it, it has to malleable enough that we can maintain it bit by bit over time

[0]: https://nx.dev/

[1]: https://rushjs.io/

[2]: https://github.com/google/wireit

[3]: https://turborepo.org/docs

In the past, I'd put a "typescript:main" field in package.json and configured my bundler to prefer that field. I gave up at some point - probably when I migrated to rollup.

Moving forward, I'm going to use wireit for these things. Pure modules get built with tsc. At the highest level (e.g. where it needs to be embedded in a page), make a bundle with rollup.

wireit has two nice properties: incremental building and file-system-level dependencies. Within a repo, you can depends on ../package-b. However, if you have multiple monorepos that often get used together, you can also depend on ../../../other-package/packages/package-b.

I've just started with wireit (it was only launched recently), but it seems to be a nice solution to wrangling dependencies between related JS libraries.

[1] https://github.com/google/wireit

Hi! Tailscalar here. This is very topical for me! Over the past 3 weeks I've been working with internal stakeholders to remove our SSO tax - the sso tax is a pet hate of mine. A couple of weeks ago we removed it from our pricing plan after my proposal was approved, and today I released a blog on our website to announce it more widely: https://tailscale.com/blog/sso-tax-cut

I knew of https://sso.tax (which we are not listed on but I did include in my blog), but didn't know there was another website too!

I'm not the person you've asked, but I'm somebody who has been purchasing SaaS/software for businesses large and small for years. My take:

1. If SSO and other basic modern security features are locked into "Enterprise" pricing tiers then the service is at the bottom of the list (see: https://sso.tax). I'd love to say instant disqualification but too many SaaS companies have it in their head that only wealthy enterprises use SSO, despite SSO platforms being widely available and some quite cheap to acquire and start using.

2. If I need to request a quote to start any kind of service to see what the product is about then I'm not likely to pursue it. Don't make me jump through hoops when I'm just trying to see if a product can fit my needs.

3. If license terms are too complex or easy to violate that's a hard pass. Infrastructure monitoring tools are a great example. The licensing is often per "device" or per monitored metric, and some vendors are very loose with their definition of "device". (Don't use LogicMonitor with k8s unless you like throwing money in the garbage can). Hard lessons learned.

4. If the only details I can find regarding how you secure your product are claims of SOC2 and ISO27001 certification then that's a very likely pass. Those controls are great to have, necessary even, but anyone who has had to work to meet those compliance objectives knows that they're much more about organization controls than they are product security. Give me an idea about how you protect data and whatnot on a security page somewhere, not an attestation that dev and prod are separate and you have logs.

On the side of the positives, outside of not hitting the negative marks, I value ease to work with, responsive and competent support, strong pre and post-sales solutions architecture and support/training (if the product is complex enough to warrant that), and supports SSO. I bring up SSO again because it's a hard requirement for SaaS purchases everywhere I go -- no SSO, no go. Social login is not a substitute and is highly undesired.

Hope this helps.

Don’t be shy, here’s the link: https://github.com/robchahin/sso-wall-of-shame/issues.

It sounds like you're unaware of why SSO is considered a security feature at all them, but it's covered right on the site: https://sso.tax/

It's to allow centralized access management. Stuff like firing someone and revoking their access from one platform instantly, instead running around and changing permissions in every tool manually. Or ensuring people in department A can't be invited to some platform for people in department B in order to limit information access.

SSO tax is predicated on the idea that the moment you outgrow the informal arrangements and liberal access, you're really a business. Seems pretty fair?

Last time I had to implement Okta integration for DocuSign at my employer it was absurdly expensive. If Google does this right then I’d be ever so happy.

DocuSign on the SSO Tax site: https://sso.tax/

There’s a strong, widespread objection to hiding security features behind a paywall: https://sso.tax/

If 2fa is the only way you can differentiate in order to force enterprises to pay, it’s better to have a fee for security than to die because you can’t make money… but broadly, as a security company, you should aim for maximum security for every user.

I totally understand. I'm aware of the SSO tax. It's just honestly a complex feature, with a significant maintenance and support burden, and I leaned making it EE so that it'd be worth all the effort to implement and maintain (i.e. I want it to be a new-positive feature for revenue). But if I could get help from other contributors, I'd be fine with SSO being a CE feature too.

Need to put them up for the SSO Wall of shame. https://sso.tax/