Refactor: Move code of lib/manager-api into ui/manager

[ndelangen]

hyper experimental: move the actual code into ui/manager but keep lib/manager-api a real package with types.

Long term strategy: move all code into a single package.

This has upside of making building manager-api unnecessary during storybookmaintenance.
the downside is that building manager is slower.

But it's a step into the right direction, I think.

Importantly this does not mean manager-api gets deprecated as a package.
It's still a package users depend on and use.

What's novel about this approach is that it doesn't need a builder to globalize manager-api! It's builder independent, because the package itself gets the implementation from the global scope.

This has a big downside:
It will only work within the browser, and only when the prebundles code is pre-injected.
You can see the effects of this in some of the tests I had to adjust.

So this is a proof of concept of the idea that we could make packages be externalised without needing to set this up in builders.

[socket-security]

No top level dependency changes detected. Learn more about Socket for GitHub ↗︎

[JReinhold]

This is interesting, looks good. Is the long term plan that we'd then remove the manager-api package completely in a major release?

I don't quite understand what you mean by the following:

It will only work within the browser, and only when the prebundles code is pre-injected.

[ndelangen]

@JReinhold what it means is:

• the user imports @storybook/manager-api they depend on it in their package.json like normal.
• the actual runtime content of the package actually reads from the global namespace though!
• the builder doesn't need to be configured to do this at all, it jut bundles code like it always does, it does not externalise anything.
• The prebundled code executes before other code, and thus the globals are there.