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.

[claudio-silva]

Your mention of sandpack.codesandbox.io made me realize this:

1. A solution like Sandpack allows running the artifact directly without a specific attached project, because it provides a generic project that can run any React code dynamically.
2. This would be good if the purpose of this project was to only run Artifacts locally. It would be simpler for the user. The same "viewer" could be reused to display multiple artifacts at runtime.
3. But that is NOT the purpose of this project, and I guess I did not explain it sufficiently well on the Readme.
4. The real purpose of this project is to aid the developer on creating a new, standard, standalone React+Vite project that can be compiled and generate an optimized, production-ready application, like any custom-made web app.
5. You can also use it as a starting point to create and expand any kind of web application, eventually mixing AI-made code with your hand-made code.
6. This is NOT just a viewer. For that, there are other better suited projects.

I guess I'll have to reformulate the Readme to make this more obvious, as I may be attracting people to this project that just want to view Artifacts outside of claude.ai, not to develop them further into a complete, standard React app.

Now, looking at your Bun setup suggestion, I should clarify something important: the project actually requires more than just the package.json and the artifact file.

An artifact can't run standalone because it needs the entire supporting infrastructure. Here's the required structure, as explained in the Readme:

- `dist/`:               Compiled output
- `public/`:             Standalone static assets
- `src/`:                Contains the source code for the application
  - `artifacts/`:        **The Artifacts generated by Claude should be placed here**
  - `assets/`:           Static assets for the build system
  - `components/`:       Bundled Shadcn UI components
  - `lib/utils.ts`:      Utility functions and helpers
  - `App.tsx`:           Main application component
  - `App.css`:           Your custom styles should be placed here
  - `index.css`:         Tailwind styles
  - `main.tsx`:          Entry point of the application
  - `vite-env.d.ts`:     Type definitions for Vite
- `.eslintrc.cjs`:       ESLint configuration
- `components.json`:     Shadcn UI components configuration
- `index.html`:          Entry HTML file
- `jsconfig.json`:       JSON configuration
- `postcss.config.js`:   PostCSS configuration
- `tailwind.config.mjs`: Tailwind CSS configuration
- `tsconfig.app.json`, `tsconfig.json`, `tsconfig.node.json`: TypeScript configuration
- `package.json`:        all the required packages are registered here
- `vite.config.ts`:      Vite configuration

Notice that these do not include the libraries installed via npm, these are just the project-specific files.

Artifacts need this infrastructure because:

1. They're wrapped in a Layout component
2. They use React Router for navigation
3. They rely on Tailwind CSS (which needs proper configuration)
4. They might use components from the ui directory
5. TypeScript configurations are needed
6. They require an HTML file with the base page structure

So, your Bun setup is insufficient because it's only getting the package.json and not all the other necessary files and configuration that your project needs to actually run an artifact. You seem to be assuming that just having the dependencies listed in package.json would be enough to run the artifact, but that's not the case.

That said, your suggestion of using Bun's template system is interesting. If I implement the npx/create command, I could use a similar approach, but I'd need to include all the required files in the template.

As for the advantages of package manager templates over git clone, I agree that:

1. The workflow would be smoother - users could create new projects almost directly from Claude without context switching
2. Projects would start clean without git history, making it easier to set up their own repository
3. It would feel more like creating a new project rather than forking an existing one
4. The setup could be more automated and user-friendly

Given these benefits, I agree that implementing a proper template system via npm/bun would be better than the current git clone approach.
I'll proceed to reformulate this project into an npm create package that properly includes all the necessary infrastructure files I mentioned above.

[Vanuan]

Yeah, I understand you need shadcm, tailwind config, etc. I couldn't find claude-like template in vite options. Might be worth exploring how to introduce claude-stack template to vite. But it could be more than Vite. Maybe users want Next.js instead or Astro or whatever. Clade itself might use entirely different stack internally, we don't know which sandboxing/server they're using.