npx?

[Vanuan]

Summary

Suggestions on improving the setup process and considering additional features for the claude-artifact-runner project. Here are the main points:

• Initial Setup:

  • Current setup requires cloning the repo, replacing content, and running the development server.
  • Suggestions to simplify this with an npx command to streamline the process.

• Feedback and Suggestions:

  • Adding an npm create or npx create feature for easier setup.
  • Introducing a single-command to run an artifact without manual setup.
  • Converting the runner into a full project with additional commands.

• Implementation Ideas:

  • Draft script for setting up local templates using Bun.
  • LibreChat may have some overlapping scope, it might be possible to collaborate on extracting car-dependencies.json into a dedicated repository
  • Highlighting benefits of using package managers over git clone for creating new projects, such as avoiding disruption of workflow, reducing unnecessary repository history, and providing predefined scripts and configurations.

• Points of Debate:

  • Whether to expand the project's functionality to include managing stored artifacts, version switching, and deployment to platforms like Vercel or Netlify.
  • Maintaining the project's focus on being a simple boilerplate versus adding more complex features.

Overall, the discussion focuses on enhancing user convenience and considering the scope of additional features.

---

Original

I would've expected easier UX. Something like:

npx car ./artifact.tsx

Maybe with optional plugins if claude will support other libraries:

npx car --type clade-react-tailwind-lucide ./artifact.tsx

Then you could extract the runner into full project:

npx car --setup ./artifact.tsx my-project

That would setup a template project with various templates. For example, vite:

npx car --setup --template vite ./artifact.tsx

You could setup multiple artifacts:

npx car --setup ./*.tsx my-project

Just something to think about

[claudio-silva]

Hi @Vanuan
Thank you for your suggestions.
It's an interesting idea.

Although it's not as if the current solution is too difficult; you just:

1. clone the repo with one command
2. replace the content of default.tsx
3. run npm run dev

With an npx command, we would reduce this by just one step:

1. create a new file and paste the artifact into it
2. run a command

Of course, it has its merits. By running npx car ./artifact.tsx, it would clone the project into a temporary folder, copy the artifact into it, install the packages and run the dev server, without touching the current directory. It would seem to the user that npx just "ran the artifact" directly. Keep in mind that it would not be instant; it would take some time (at least for the first run, subsequent runs could reuse the temporary project).

As for supporting other libraries, that is out the scope of this project, though, as it would not make sense for Artifacts. They are supposed to run in Claude's website, so we are restricted to Anthropic's choices of tech stack. If we go out of that scope, then the users would not be making Artifacts at all, they would be making React components that couldn't be previewed on the online Artifact's viewer. In that case, they would be better off using Cursor or some other tools (e.g. Bolt.new).

Nevertheless, these options do seem interesting:

1. npx car ./artifact.tsx
2. npx car --setup ./artifact.tsx my-project
3. npx car --setup ./*.tsx my-project

I'll think about it.

[Vanuan]

Well, If I'm going to set up my own repo, why would I go with claude-artifact-runner?

Compare:

git clone ...
paste into default.tsx
npm run dev

vs

npx create ...
paste into App.tsx
npm run dev

If I could just download the artifact, open the terminal and run it in a single command:

npx run ~/Downloads/artifact.tsx

Which would open the artifact in a browser.
Then I could see the benefit of CAR. Until then, it's just the same project starter for me. Which doesn't even have the npm create simplicity.

Just thought you would like a feedback.

---

Of course, you could go in a completely different direction.
To motivate me git cloning the CAR, it should have much more functionality:

• manage my stored artifacts
• version switcher, just like in claude
• deploy to vercel/netlify

But if the initial setup becomes complicated, bolt.diy would make a better return of the time investment.

[claudio-silva]

"why would I go with claude-artifact-runner?"

Well, you need to have a project boilerplate to start from, and no, a generic React+Vite boilerplate (or similar) is not enough; you would still have to add all required dependencies and components that match what Claude believes is available on the Artifacts environment.
And that's what this project provides. It is not supposed to be a big, complicated project, it's just a custom boilerplate/scaffold to save you time, a routing system for easily adding new pages, and a nice Readme with instructions for guiding you on updating it and deploying it (it mainly targets less skilled developers or even non-developers toying with AI generated code). Still, I believe it may have value even for experienced developers, just as a convenience.

You do make some interesting points, though.
Yes, if the file is created by downloading it from the Artifact panel, then the user would just have to run a single command.
It would be as simple as it gets! 🙂

So, I will accept the suggestions that make the project even more convenient:

1. Add an npm create or npx create feature.
2. The single-command to run an artifact (or several) without manually cloning and setting up the project.
3. The command to convert the runner into a full project.

As for the "completely different direction", I'm not convinced it would be wise to expand the project's focus too much, as that would make it useless for the intended target audience: the more features we add, the more it loses the appeal of being a simple boilerplate to serve as a starting point for an app based on an Artifact.

It could be an interesting idea for a new project, though, but I'm not sure there would be enough interest to justify building it.

Anyway, thanks for taking the time to provide some feedback. I do appreciate it. 🙂

[Vanuan]

Here's some draft for setting up bun local templates:

# Step 1: Create Local Template for `car` using Bun
mkdir -p ~/.bun-create/car && cd ~/.bun-create/car

# Step 2: Curl the package.json file
curl -O https://raw.githubusercontent.com/claudio-silva/claude-artifact-runner/main/package.json

# Step 3: Add bun-create section to package.json
jq '. + { "bun-create": { "preinstall": "echo Installing...", "postinstall": ["echo Done!"], "start": "bun run echo Hello world!" } }' package.json > tmp.json && mv tmp.json package.json

# Step 4: Verify the project setup
echo "Template car set up in ~/.bun-create/car"

This script will:

1. Create a local template directory for car.
2. Fetch the package.json file from the specified GitHub repository.
3. Add the necessary bun-create section to the package.json.

Usage:

bun create car <new-directory>
cp ~/Downloades/artifact.tsx <new-directory>
cd <new-diractory>
bun run

Though, bun may need some adjustments: https://bun.sh/guides/ecosystem/vite

This way, you don't need to clone anything, just run the template installation script.

If this works, you could build upon it and publish in on npm, so that it will work with npx and yarn create as well.

[Vanuan]

BTW, a list of claude artifact dependencies appears to be maintained here:
https://github.com/danny-avila/LibreChat/blob/433ac1eba4aa2967f6b9f44722bf8b25ab23e919/client/src/utils/artifacts.ts#L118-L173
Though it's not official either.

LibreChat uses sandpack in case you decide to extend the project scope:
https://github.com/danny-avila/LibreChat/blob/433ac1eba4aa2967f6b9f44722bf8b25ab23e919/client/src/components/Artifacts/ArtifactPreview.tsx#L46-L77

[Vanuan]

You might ask how npm/bun/yarn create <template> is different from git clone.

Here are the cons of the latter:

1. You need to navigate to the repo, copy the clone command, return to the terminal, and paste the command. This disrupts the mental workflow as you switch between Claude, GitHub, and the terminal.
2. If you decide to push your project to your GitHub, you'd have to clone it, rename it, etc. This was the workflow before templates were introduced in package managers, but it causes every project to be a fork of a template. A template is intended to be a different entity from the project itself.
3. git clone often brings in the entire repository history, which is unnecessary for creating a new project and can increase the download size and time.
4. Using git clone means you have to manually remove the .git directory if you want to start a fresh repository, adding extra steps to the process.
5. Templates managed by package managers often come with predefined scripts and configurations tailored for quick setup, which might not be the case with a generic git clone.

P.S. I've summarised the discussion for easier reference.