Envrionment conditions selector is frustrating yet hilarious

[BANOnotIT]

fucked.up.switches.2.mp4

1. Why use switches instead of check boxes and radio buttons?
2. Why uncheck something when I check the other thing?
3. Why uncheck something if I can check it manually back?

[guybedford]

I'm glad you found this entertaining. It's a concept called a "constraint":

• The development and production conditions are mutually exclusive (see the Node.js documentation - https://nodejs.org/api/packages.html#community-conditions-definitions)
• Node.js and the browser are also mutually exclusive
• Deno and Node.js are different platforms

Since this was originally set up, Deno has made the decision to fully embrace Node.js compatibility and even mimic Node.js by supporting features like process.env.node. As such the last constraint could be relaxed at this point and we could allow and even default the "node" condition when setting "deno".

Feel free to dig into constraints which you find reproachable further, if you care enough to share a considered thought.

[BANOnotIT]

These "constraints" are purely technical, and nothing in UI shows how do they work. Only Dev/Prod selector works "reliably", every other switch may live its own life depending on state of some switches around and depends on the order of switches being clicked.

For example:

Node.js and the browser are also mutually exclusive

At 0:12 you can clearly see that both of them are turned on. So it's occasional exclusivity, which can only be deducted from states of other switches. Also at 0:08 when I click "Deno" it turns off "Browser" and turns on "Node", in the next second I can manually turn "Browser" on, which makes it more frustrating: why would you turn it off if it can be turned back on?

This basically becomes a Guardian's Puzzle to find the correct order of buttons to press to open up some ancient door.

---

So I would really suggest making it obvious with usage of radio buttons and by moving "unsetting" behavior and conditions "compatibility" section which can "fix" incompatible checkboxes when the person explicitly wants that compatibility being applied.

This is what I'm proposing in UI view:

1. Radio for Dev/Prod that explicitly shows their relation
2. Check boxes for "features" to be enabled, these are mutually not constrained
3. Compatibility section which shows ✅ when platform compatibility is achieved and shows "Enable" button to "fix" (enable/disable) of contradicting features.

[guybedford]

This is great, and I agree, thanks for clearly explaning your suggestion!

Radio buttons for development and production makes a lot of sense, I've posted jspm/generator.jspm.io#63.

For the deno / node case the reasoning here is that you can build for Node.js - or you can build for Deno, and when building for Deno you want node compat, but when building for Node you don't want to have deno compat. I like your idea of a separate compat / platform selector though. Maybe it's even just a platform dropdown (Node | Browser | Deno | Cloudflare Worker etc) (posted jspm/generator.jspm.io#64).

Beyond the UI, these concepts also need to be translated into JSPM CLI flags / generator environment setting where today these are all bags of bools. I wonder if there's some sensible ways to do that as well, more explicitly defining production/dev, platform flags etc.