SolidJS•2y ago

SolidStart prod build fails to start on `require()`

My site uses a library algosdk that has dependencies which utilize require() in them, which cause the production build to fail with the below error.

undefined:1
require('crypto')
^

ReferenceError: require is not defined in ES module scope, you can use import instead
This file is being treated as an ES module because it has a '.js' file extension and '/Users/name/Code/alright-solid/package.json' contains "type": "module". To treat it as a CommonJS script, rename it to use the '.cjs' file extension.
    at eval (eval at nodeWrap (file:///Users/name/Code/alright-solid/dist/server-86e62de6.js:25657:19), <anonymous>:1:1)

undefined:1
require('crypto')
^

ReferenceError: require is not defined in ES module scope, you can use import instead
This file is being treated as an ES module because it has a '.js' file extension and '/Users/name/Code/alright-solid/package.json' contains "type": "module". To treat it as a CommonJS script, rename it to use the '.cjs' file extension.
    at eval (eval at nodeWrap (file:///Users/name/Code/alright-solid/dist/server-86e62de6.js:25657:19), <anonymous>:1:1)

41 Replies

Alex Lohr•2y ago

You need to use import instead of require.

SilentRhetoricOP•2y ago

It isn't my code, though, this is buried two dependencies deep in a library There must be a way to do this because I can use this library in a React + Webpack client side app just fine But I cannot get a Solid Start build to run In Webpack 5 I can use some polyfills through react-app-rewired So perhaps there is a similar approach that could work with SolidStart + Vite?

Alex Lohr•2y ago

Maybe this works for you: https://github.com/vitejs/vite/issues/4209#issuecomment-919661782

GitHub

Commonjs import differs between dev & prod · Issue #4209 · vitejs/...

Describe the bug Bug A commonjs module default import will give a function in dev and an object in prod, resulting in an error on prod X is not a function Repro npm run dev Then check the console, ...

SilentRhetoricOP•2y ago

Very interesting, let me read this The very next comment is concerning... esbuild in dev and rollup in prod Would be great if that was unified

Alex Lohr•2y ago

Vite already uses rollup for prod.

SilentRhetoricOP•2y ago

yes we are saying the same thing but the very next comment highlights the inconsistency between dev and prod

SilentRhetoricOP•2y ago

https://github.com/vitejs/vite/issues/4209#issuecomment-920938852

GitHub

Commonjs import differs between dev & prod · Issue #4209 · vitejs/...

Alex Lohr•2y ago

What is concerning you about that? eslint is specifically meant for pre-production purposes?

SilentRhetoricOP•2y ago

As a general statement, it is frustrating to have something work in dev and then fail in the prod build

Alex Lohr•2y ago

That's the price you pay for the faster development.

SilentRhetoricOP•2y ago

That's kind of a flippant thing to say to someone trying to learn Solid/Start I'm about 30 seconds from going back to React + Next You're on the growth team? lol I put a beginner tag on the help thread...

Alex Lohr•2y ago

Sorry, I meant to say the price we pay. If you want to use solid with webpack, I can help you to get there, too.

SilentRhetoricOP•2y ago

Is the limitation at play here a function of Vite or of Solid Start?

Alex Lohr•2y ago

This is a limitation of vite. Yet also a strength, because the same distinction allows for things like hot module reloading during development.

SilentRhetoricOP•2y ago

I am going to read this thread here, too: https://github.com/vitejs/vite/discussions/4921

GitHub

Thoughts on dependencies handling · Discussion #4921 · vitejs/vite

Some thoughts regarding dependencies / SSR / prod vs dev: Apply plugins to non js/ts files found in dependencies during the pre-bundle phase. fixes e.g. #3910 avoids having to manually exclude pack...

Alex Lohr•2y ago

I was going to research how to use turbo.build instead of vite for solid, but they currently only support react-style JSX transpilation at the moment and the swc plugin API is not yet stable.

SilentRhetoricOP•2y ago

What do you think about this comment? https://github.com/vitejs/vite/discussions/4921#discussioncomment-3762142

GitHub

Thoughts on dependencies handling · Discussion #4921 · vitejs/vite

SilentRhetoricOP•2y ago

They mention an experimental Vite feature that is disabled by default

SilentRhetoricOP•2y ago

https://vitejs.dev/guide/migration.html#using-esbuild-deps-optimization-at-build-time

Vite

Next Generation Frontend Tooling

Alex Lohr•2y ago

It comes with the drawback that your production resources are less optimized than they would be by rollup. How much difference that will make is anybody's guess.

SilentRhetoricOP•2y ago

I'm new to this, but a wise person once told me that premature optimization is the root of many problems

Alex Lohr•2y ago

You may have noticed that our community is pretty interested in performance.

SilentRhetoricOP•2y ago

When you say less optimized, do you mean for build speed or final JS size?

Alex Lohr•2y ago

You know Don Knuth?

SilentRhetoricOP•2y ago

no lol should I?

Alex Lohr•2y ago

Final JS size. He was the wise person who came up with that quote.

SilentRhetoricOP•2y ago

oh haha thank you I will read about him

Alex Lohr•2y ago

Otherwise, he is known for creating the LaTeX typesetting engine.

SilentRhetoricOP•2y ago

OK so my "things to try" checklist include the experimental Vite feature, and, failing that, the @rollup/plugin-commonjs plugin

Alex Lohr•2y ago

Anyways, back to your current issue. Once you use HMR, the code you are running during development is going to differ from the production code. It's a compromise for the sake of development speed and convenience.

SilentRhetoricOP•2y ago

So with that in mind, what do you think about this advice? Include a minified browser bundle directly in your HTML like so: <script src="https://unpkg.com/[email protected]/dist/browser/algosdk.min.js" integrity="sha384-1gIB0FiLMNmJ7adAfBOdH20Mnw0DZarB9D3PTozUAhKn/uT9CpHdaSbBIpmZTgrU" crossorigin="anonymous" ></script> Should I import algosdk normally for development but have the browser bundle utilized from there for production?

Alex Lohr•2y ago

We do have a community primitive collection including a "script-loader" primitive: https://github.com/solidjs-community/solid-primitives/tree/main/packages/script-loader

GitHub

solid-primitives/packages/script-loader at main · solidjs-community...

A library of high-quality primitives that extend SolidJS reactivity. - solid-primitives/packages/script-loader at main · solidjs-community/solid-primitives

Alex Lohr•2y ago

If you want to load it async in both cases.

SilentRhetoricOP•2y ago

Oh very interesting

Alex Lohr•2y ago

Not sure if that package will benefit from tree shaking. In that case, it may be better to use it as a dependency.

SilentRhetoricOP•2y ago

it probably would there is a bunch of stuff in it of which I need a small fraction so that would mean avoid the script-loader? It seems like my path forward is: 1. Try the experimental Vite feature 2. Try the commonjs plugin 3. Try the script-loader primitive

Alex Lohr•2y ago

Only if the benefits of tree shaking were significant. Sounds like a good plan. 4. could be to ask the developers of the package in question to fix their broken exports.

SilentRhetoricOP•2y ago

On this point, the actual issue isn’t even in this library, it is secondary dependencies underneath. Thanks very much for your help, I have a lot to do now to see if I can get this working

Unknown User•2y ago

Message Not Public

SilentRhetoricOP•2y ago

lmao @lexlohr Just to circle back here, I made some basic attempts on 1 & 2 above and then, upon further reflection, decided that using Solid Start fell into the category of "premature optimization" just for SEO on my landing page with no added value to other parts of my product. I rewrote my app in a vanilla Solid + Vite repo and managed to get it to dev + build + start successfully with some configuration, which I have shared below. Therefore, I have decided to abandon Solid Start given its current state, added complexity, and limited marginal value for my use case, which is intended to move logic & state to the client as much as possible. The following vite.config.ts got me up and running from the Solid Typescript Minimal starter template:

import { defineConfig } from 'vite'
import solidPlugin from 'vite-plugin-solid'
import tsconfigPaths from 'vite-tsconfig-paths'
import inject from '@rollup/plugin-inject'
import { NodeGlobalsPolyfillPlugin } from '@esbuild-plugins/node-globals-polyfill'

export default defineConfig({
  plugins: [solidPlugin(), tsconfigPaths()],
  server: {
    port: 3000,
  },
  build: {
    target: 'esnext',
    rollupOptions: {
      plugins: [inject({ Buffer: ['buffer', 'Buffer'] }),],
    },
  },
  optimizeDeps: {
    esbuildOptions: {
      // Node.js global to browser globalThis
      define: {
        global: 'globalThis',
      },
      // Enable esbuild polyfill plugins
      plugins: [
        NodeGlobalsPolyfillPlugin({
          buffer: true,
        }),
      ]
    }
  },
})

import { defineConfig } from 'vite'
import solidPlugin from 'vite-plugin-solid'
import tsconfigPaths from 'vite-tsconfig-paths'
import inject from '@rollup/plugin-inject'
import { NodeGlobalsPolyfillPlugin } from '@esbuild-plugins/node-globals-polyfill'

export default defineConfig({
  plugins: [solidPlugin(), tsconfigPaths()],
  server: {
    port: 3000,
  },
  build: {
    target: 'esnext',
    rollupOptions: {
      plugins: [inject({ Buffer: ['buffer', 'Buffer'] }),],
    },
  },
  optimizeDeps: {
    esbuildOptions: {
      // Node.js global to browser globalThis
      define: {
        global: 'globalThis',
      },
      // Enable esbuild polyfill plugins
      plugins: [
        NodeGlobalsPolyfillPlugin({
          buffer: true,
        }),
      ]
    }
  },
})

Alex Lohr•2y ago

Thanks for the feedback.

Gaming

Programming

SolidStart prod build fails to start on `require()`