How to surface community adapters / templates

[ryanflorence]

Background

We shipped with a handful of adapters and templates to show that you can ship Remix anywhere and help out early adopters. Managing all of them in the Remix source code, however, is unmanageable long term.

We will never have deep knowledge of every server's request/response API and deployment platform's special features (for example #1835). Even more difficult is that many emulate the real server in development and have differences in development vs. production!

Another concern is that we currently version the remix packages in lock step. If a particular platform changes their API then that affects our versioning in Remix. For the time being, we'd like all Remix packages to stay in lock step.

We also don't want to give the impression we're trying to pick favorites. We often receive pull requests to support koa or restify or some other server we have no experience with.

Finally, since Node.js has added fetch in v17, and other JS environments already support it (Deno, Cloudflare, Fastly), we eventually might not even need adapters in the Remix source code.

What should we do?

We will continue to support the adapters we have, but we don't intend to add any new ones. In fact, we intend to move the adapters and templates to the community and the platforms/servers/hosts they work with moving forward.

What we need is a way to surface adapters to the community. Usually an adapter needs a solid starter template to go along with it as well.

A knee-jerk reaction to this is for us to:

• adapters: Add a page in the docs that lists all the community adapters and starter template repositories. Instead of adding an adapter/template to the Remix source repo, folks send a PR that adds a links to the page
• templates: In addition to the official starter templates, add an option to pick a community template in the create-remix command

Anybody have thoughts on this? Thanks!

[sergiodxa]

I had the same problem with strategies on Remix Auth and decided to move them to be owned by the interesting people (whoever care about that strategy in particular).

What I did was to create a discussion on the repo where people can mention the strategies they like.

I like a lot the Passport.js approach of creating a page on their docs to link the strategies, if you go to https://www.passportjs.org and click on Strategies on the sidebar it will show a list of all strategies published to npm, when you click them it will show a special hosted page showing the README of the strategy (e.g. https://www.passportjs.org/packages/passport-local/) with some information like the download, repository link, etc.

I think people or companies publishing their adapters for Remix could add a special keyword like remix-adapter on their package.json and then Remix could fetch from npm all the packages with that keyword, also maybe require a namespace on their names like remix-adapter-koa and remix-adapter-restify and use both keyword and namespace to filter packages from npm.

I also like the idea of having official starters and community ones, I remember someone sent a PR to let create-remix create the app using an external repo as template, I like that idea, you can do npx create-remix my-app --template sergiodxa/remix-template and create-remix can just clone the template into my-app and that's all (or ask for a name if it was not provided), that way the CLI can have some official templates as options or you can provide your own, I think it will be useful for web development agencies using Remix too, they can create a template with all the things they use already setup and use the CLI to clone it.

Another thing the CLI could do is to let you clone any example from the examples folder in the repo, something like npx create-remix my-app --template socket.io and clone the socket.io example, you can say that org/repo search on GitHub and just name is an example.

Also for template repos, you could verify the repository is marked as a template on GitHub before cloning it, and request that, as a way to ensure you don't just clone any repo.

[thomasgauvin]

@ryanflorence, it would be great if the deployment targets and the adapters (both official and community) were listed in the docs. That's the first place I checked, and I didn't initially find information (only going to other blogs or trying out the CLI myself was I able to find out what the supported deployment targets were). I also think it would be interested to document how to get started with writing custom deployment adapters