Split packages

[frandiox]

I'm proposing here a slightly different way to organize our packages:

• packages/remix-oxygen (maybe released as @remix-run/oxygen, eventually owned by the Oxygen or Remix folks): Oxygen adapter for Remix. It contains a createRequestHandler for Oxygen.
• packages/hydrogen (released as @shopify/hydrogen@2): core package for Hydrogen utilities. It exports cache utilities (CacheShort, CacheLong, etc) and a createStorefrontClient that returns the storefront utility and a fetch with server caching capabilities. This is pure JS so it can be used with any framework. Probably some of our Hydrogen UI utilities (e.g. getPublicTokenHeaders, etc.) should also live in this core package.
• packages/hydrogen-remix (released as @shopify/hydrogen-remix): This is a wrapper around hydrogen and remix-oxygen. It exports a createRequestHandler that knows how to create the storefront object and inject it in Remix context. It also re-exports everything from those two packages so that developers who use Remix, Hydrogen and Oxygen only need to import stuff from @shopify/hydrogen-remix. Optionally, we can include @shopify/hydrogen-remix/node to support raw Node runtimes (e.g. Stackblitz).
• cli (should be merged with the official Shopify CLI package at some point): builds for Remix+Hydrogen+Oxygen; develops for Remix+Hydrogen+Oxygen; previews for Oxygen (worker bundle can use any framework since this is just a wrapper around mini-oxygen).

Scenarios:

• App building with Remix and Hydrogen, deploying to Oxygen: depends on @shopify/hydrogen-remix and @shopify/hydrogen-react.
• App building with Remix and Hydrogen, deploying to a 3p provider: depends on @shopify/hydrogen, @remix-run/{provider} and @shopify/hydrogen-react.
• App building with Next.js: depends on @shopify/hydrogen and @shopify/hydrogen-react.
• App building with Nuxt (Vue): depends on @shopify/hydrogen and ??.

Thoughts? @jplhomer @frehner

[frehner]

packages/hydrogen (released as @shopify/hydrogen@2): core package for Hydrogen utilities. It exports cache utilities (CacheShort, CacheLong, etc) and a createStorefrontClient that returns the storefront utility and a fetch with server caching capabilities. This is pure JS so it can be used with any framework. Probably some of our Hydrogen UI utilities (e.g. getPublicTokenHeaders, etc.) should also live in this core package.

Is this a duplication of the hydrogen-ui package? In other words, hydrogen-ui will soon be a place for framework-agnostic utilities (probably @shopify/hydrogen-core or something like that) as we extract out the pure-JS functions from the React package, and then use them to build other framework adaptors. It seems like, rather than make another one of those libraries, that these should just be in hydrogen-ui instead? It would potentially be pretty confusing to know where a pure-JS function should go, right?

[frandiox]

hydrogen-ui will soon be a place for framework-agnostic utilities (probably @shopify/hydrogen-core or something like that)

I think we are basically talking about the same package, it's just an issue around naming. Somehow I thought that the @shopify/hydrogen-core you are mentioning would be released directly as @shopify/hydrogen @2.0.0.
I guess my question is, if we are releasing @shopify/hydrogen-core, then what's going to happen to @shopify/hydrogen? Do we keep it for Hydrogen 1.x forever? 🤔

[jplhomer]

I'm good with this distinction. While one could argue that @shopify/hydrogen is now agnostic to all React meta-frameworks, I don't think we should think of it like that and continue to lean into the idea that this is the opinionated way to create a Hydrogen storefront out of the box.

@shopify/hydrogen-ui etc should continue to lean into the agnostic aspects.

[blittle]

@frandios where do you think the routing abstraction should live? It is specific to remix, not necessarily Oxygen. packages/hydrogen-remix ?

[frandiox]

@blittle I think it would make sense in @shopify/hydrogen-remix, yes.
One thing about this package that I was considering is that we can support Node targets as well.

Basically, we can provide @shopify/hydrogen-remix/node as an entry point for non-Oxygen environments, or even rely on Node export conditions during build. Something like this:

"exports": {
  "worker": {"./*": "./dist/oxygen/*"},
  "default": {"./*": "./dist/node/*"},
}

Remix is already adding worker condition when building for CFW/Oxygen and we can do the same by default, unless the user pass "target: Node" somewhere (CLI flag or remix.config.js).

This way we can keep supporting Stackblitz for reporting issues and quick examples without changing the app, just a flag and perhaps the worker/server entry file.

[blittle]

@frandiox thoughts on where the demostore template should live? We could do the same as hydrogen 1, and put it inside a templates directory. @benjaminsehl also has an issue to create a hello world starter template

[frandiox]

@blittle Already did exactly that in #186 :)

[benjaminsehl]

@frandiox thoughts on where the demostore template should live? We could do the same as hydrogen 1, and put it inside a templates directory. @benjaminsehl also has an issue to create a hello world starter template

@juanpprieto has been playing with the idea of a /templates folder inside a Hydrogen project. If we do move forward with that, would maybe be weird to have that name re-used.

What about /starters?

[frandiox]

I'm going to be merging this to prevent more conflicts. We can change the package folders easier if we decide so.

[frandiox]

would maybe be weird to have that name re-used.

@benjaminsehl Not sure what you mean with having it re-used. It's just a templates directory at the root, and then templates/demo-store, just like we have in H1, no?

[benjaminsehl]

@frandiox — yeah, didn't know if that was confusing or not for people … just taking the opportunity to rethink that naming.

On the topic of naming the packages … +1 to @jplhomer's commend: @shopify/hydrogen should be the opinionated take. Everything else we'll put into hydrogen-ui unless we arrive at a place where our "full stack" tooling goes agnostic.

So …

Scenarios:
App building with Remix and Hydrogen, deploying to Oxygen: depends on @shopify/hydrogen-remix and @shopify/hydrogen-react.
Ideally importing just @shopify/hydrogen, and any @remix-run/* packages (and obviously react)
App building with Remix and Hydrogen, deploying to a 3p provider: depends on @shopify/hydrogen, @remix-run/{provider} and @shopify/hydrogen-react.
I'd just merge this point with the above one and have @remix-run/oxygen as you said.
App building with Next.js: depends on @shopify/hydrogen and @shopify/hydrogen-react.
Would just be `@shopify/hydrogen-ui
App building with Nuxt (Vue): depends on @shopify/hydrogen and ??.

@dalmaer has some friends at NPM/Github and we can potentially get our issue pushed forward to get hydrogen and @hydrogen/* … ultimately that's the route I'd prefer to go long term.

• @hydrogen/core for what you're proposing as @shopify/hydrogen
• hydrogen for what you proposed as @shopify/hydrogen-remix

I'd also suggest that in addition to @hydrogen/react we eventually add a package like @hydrogen/next — that could provide specific functionality for those metaframeworks (and ideally just re-exporting @hydrogen/react) … for example, a Next package would provide a "loader configuration" for Imagery: https://nextjs.org/docs/api-reference/next/image#loader-configuration.

[rennyG]

@benjaminsehl given the list of repos and options for building, do you think partners would benefit from guidance? Like a What do you want to do? Or I want to and then we list the build options and the repos for each.

Apologies if I'm getting ahead of myself here!