How to have testable Javascript in a Phoenix LiveView Project?

I was really surprised that no one had an approach to share on how to have testable JavaScript in a Phoenix project.

I will share my approach:

1. Created a pure TypeScript package at assets/vendor/package-name, with strict set to true and with Vitest for the test runner.
2. I write all my TypeScript code for the LiveView Hooks with tests.
3. I include each hook in assets/js/app.js.
4. I assign the hook as usual with phx-hook and if needed I configure it via data-* attributes in the heex template.

The assets/vendor/canvas/package.json:

{
  "type": "module",
  "devDependencies": {
    "@types/jsdom": "^27.0.0",
    "@types/node": "^24.10.1",
    "jsdom": "^27.2.0",
    "typescript": "^5.9.3",
    "vitest": "^4.0.8"
  }
}

The assets/vendor/canvas/tsconfig.json:

{
  "compilerOptions": {
    "target": "ESNext",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "strict": true,
    "allowJs": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "outDir": "./dist",
    "types": ["vitest/globals", "node"],
    "baseUrl": ".",
    "paths": {
      "@src/*": ["src/*"],
      "@test/*": ["test/*"]
    }
  },
  "include": ["src/**/*.ts", "test/**/*.ts"],
  "exclude": ["node_modules", "dist"]
}

The assets/vendor/canvas/vitest.config.ts:

import { defineConfig } from "vitest/config";
import path from "path";

export default defineConfig({
  test: {
    environment: "jsdom",
  },
  resolve: {
    alias: {
      "@src": path.resolve(__dirname, "./src"),
      "@test": path.resolve(__dirname, "./test"),
    },
  },
});

If the JS is written by your team, you can create sibling files to app.js that export testable public functions. Unit test those functions with a JS testing framework like vitest. If you want to test your JS’s integration with your backend, use an end-to-end testing framework like Wallaby or Playwright.

As a general rule, write unit tests that test “when [input], then [output]” for the all of the input cases your app needs to handle.

And if you do add end-to-end tests, only write tests for the happy path, as e2e tests are far slower and often have some flakiness to them, even when skilled people write them.

Happy testing!

Hey @Exadra37 , looks like I was responding to you just as you wrote your follow-up. Overall, I think you landed in a good place for unit testing your JS.

I would make a few tweaks, but feel free to ignore them if you’re happily on your way:

1. If the JS source code you’ve written for your canvas abstraction is completely authored by your team, I would move the code out of assets/vendor/, as that directory is traditionally used for third-party code. You can instead house your js in assets/js as direct descendant files (or in a subdirectory if you have many modules that you want to semantically group)
2. You can simplify your tsconfig ←→ vitest.config by creating your test files as direct siblings of the modules they test. Then your test files can import the modules under test using very simple relative paths, i.e. import { funcToTest } from "./canvas" . That will allow you to remove the various aliasing configs you’ve set up, which, I can tell you from experience, can lead to configuration maintenance headaches over time. If you want to go that route, I’d use file infixing for the test files, where your test files would look like canvas.test.ts

Either way, happy you landed in a decent spot. Test on!

Thanks for your feedback

The reason to have it in the vendor folder is that I want the package to be reusable in other projects, therefore agnostic from the current application.

Regarding the rest of the setup it was mainly Gemini Pro who decided on it, because I am a beginner when it comes to TypeScript. I just asked to create a package that followed the best practices in TypeScript, but to be honest I didn’t check what they were, because the proposal mirrored what I am used to see across programming languages, tests and source code separated.

Your proposal of joining tests alongside the module under test are also interesting, because its immediately obvious when some source code is not being tested at all. I will give it a though