Move to a single package that targets ES2017 and ESM only

[dhh]

In preparation for moving to @hotwired/stimulus, we're going to collapse the separate packages into a single one. The individual packages didn't see material usage, and complicated the internal setup, as well as required extra tooling.

This also makes the move to produce a ES2017/ESM rollup.

Work remaining:

• Get tests running again
• Get examples running again

[Sub-Xaero]

👍 This will make DX with Typescript and IDE intellisense much better.

All the IDEs I've used have struggled to resolve the full typings for Controller et al from the parent package.

[dhh]

@Sub-Xaero Excellent! If you feel like helping out getting either tests or examples running again, please have at it ✌️

[leastbad]

I don't have the full context or background on this migration, but the language suggests that you're switching npm package names. This would break 100% of existing Stimulus controllers, including the entire ecosystem of published controllers in addition to the controllers that live in applications.

There's an easy solution: continue to publish updates to the current stimulus package, which just imports your new @hotwired/stimulus package. (Technically, the stimulus package already does this, with all of the separate packages. This would just change out the libraries that stimulus depends on.)

This way, everyone is happy and nothing is broken: you can market @hotwired/stimulus as the definitive home for the library, and the 17,348 public controllers (it's probably at least 10x this private) aren't scrambling to change references.

[dhh]

That’s the plan, @leastbad 👍

[dhh]

On second thought, I'm not sure it makes sense to have stimulus remain a redirection to @hotwired/stimulus. This is a major version bump, and the old stimulus 2.0.0 package is going to be where it is forever. So anyone wanting to make a major version jump in their use of stimulus can certainly change the reference in their dependencies from stimulus to @hotwired/stimulus, no? All the code that's currently out there will continue to work just fine, pointing to the old location we have for 2.0.0.

[dhh]

Although I suppose the advantage is not having to upgrade "import { Controller } from 'stimulus'" lines. It's just that this new setup uses a single package, instead of the split out ones before. And we're not going to release those sub packages. Not sure it's worth it.

[leastbad]

David, I am begging you not to change course from what you agreed was the plan not long ago. A package change would have ruinous impacts on the Stimulus community, which now extends far beyond the Rails ecosystem.

It's a transition which would never be fully complete. There are now hundreds of 3rd-party Stimulus controllers out there, and the moment that there's two package names, everything just goes to shit in the dependency graph.

Suddenly package maintainers have to choose between having access to new features and bug fixes and breaking every project that relies on them, or waiting until some future moment where everyone has independently do some hidden calculus on when the exact right moment to cut over is. It's an albatross.

It's not like people can just have both in one project. Even if sending two versions of Stimulus down the wire worked or could be a solution, it would require having two active Stimulus Application contexts in one app. And for what?

Also, I think that there's a legitimate concern that this change looks bad on the library, just when we're starting to get real adoption. I don't want to dwell on politics, but this is not nothing.

The fact that everything is going to be in a single package is great. That's a super-positive change. It doesn't change anything about what I'm talking about; I'm not sure I've ever seen a single instance of people importing those sub-modules in a project.

There's simply zero downside to maintaining the stimulus package as a shim that points to the latest @hotwired/stimulus package. Let people switch over at their own speed. Just have both!

Do you remember how badly the Angular team fucked up the transition between v1 and v2? They were the leader of the pack, but never ever recovered from the decision. Everyone said, "how could this happen?" but I guarantee you that there was a well-intentioned "it'll be fine" conversation with someone wielding great power involved.

[joshleblanc]

One of the problems with introducing a new package name without maintaining support for the existing package name, is that anyone who's depending on a stimulus NPM package that doesn't update to the new name will actually pull in stimulus twice.

So if your default rails app installs @hotwired/stimulus, and my-sick-stimulus-select depends on stimulus, you're going to end up with 2 different versions of the same package in your application.

On a more philosopical side, it breaks the principle of least astonishment. Ideally, a user (developer) shouldn't be surprised by anything while updating a package, and I'd posit that changing the name of the package entirely would count as a surprise.