[Feature]: Allow custom esbuild-Plugins through remix.config.js

[l-mbert]

What is the new or updated feature that you are suggesting?

Allow us to add esbuild-Plugins through the remix.config.js so we can bundle our for Example CSS with PostCSS, SASS or more. I know it was already suggested in #192 and "declined" because the Team isn't comfortable with locking into esbuild.

I understand that but would like to propose a different Idea for the time being: allow us to set a new Key like dangerouslySetEsbuildPlugins so we can add esbuild-Plugins.

Why should this feature be included?

So we can bundle our CSS in our Way without the need to setup another CLI Process (which isn't Hard I agree but could be avoided with a single Key for us to use). And we could use the Folder Structure like it was intended and don't have another styles-Folder in a different Location.

This would of course just be a temporary "fix" until a better Solution for processing CSS is found which will officially be supported by Remix. Since it's named dangerouslySetEsbuildPlugins (or something else) it could be documented as just a Way for now and that it will be removed in a later Update.

[jacargentina]

In my case, my NextJS codebase has Flow annotations.

I'm evaluating switching to Remix, there are some features which are very attractive, but having to remove all our flow annotations is a very bold decision.

Hoping for a re-evaluation of this possibility from the team.

[ionut-botizan]

I'd also like to see support for esbuild plugins as that will (hopefully) allow us to use LinariaCSS in a Remix project. If you're not familiar with it, Linaria is a zero-runtime CSS-in-JS library that compiles your styles into static CSS files at build time, offering a great mix of DX and runtime performance.

Some of its (cherry-picked) benefits are:

• Scoped selectors
• Automatic unused styles removal
• Automatic vendor prefixing
• Static CSS (doh) that can be loaded in parallel to JS
• Works without JavaScript
• Full power of CSS / No new syntax to learn (you just write CSS in a tagged template literal) with JS variables/expressions interpolation.

Basically, we get to write something like the following but still have all the benefits of serving plain CSS that needs no runtime JS:

// src/styling/theme.ts

export const theme = {
    colors: {
        primary: 'hotpink',
        // ...
    },
    spacing: { sm: 8, md: 12, lg: 24 }
    // ...
} as const

// src/pages/Home.styles.ts

import { css } from '@linaria/core'
import { lighten } from 'polished'
import { theme } from '../styling/theme'

export const button = css`
  background-color: ${theme.colors.primary};

  &:hover {
    background-color: ${lighten(0.2, theme.colors.primary})};
  }
`

[mikestopcontinues]

I recall the argument against being that the team wants the ability to swap out build engines in the future. I get that, and I'd rather they be able to stay nimble. (Look at Next stuck on Webpack!) That seems like it means a remix-plugin API is coming some day. That's awesome, but in the meantime, it still seems like an __unsafe__esbuildPlugins config option is warranted. Force users to opt into an interim solution, and get to break the API whenever you want, right?

[jenseng]

I found a way to do this, though the standard caveats apply (shameful hack, unsupported, subject to break in the future, etc., etc.) 😄 ... If you create an esbuild-overrides.js like so:

const esbuild = require("esbuild");
const Module = require("module");

const originalRequire = Module.prototype.require;
const originalBuild = esbuild.build;

const build = (options) => {
  return originalBuild({
    ...options,
    // add in your overrides here, making sure to preserve original nested options., e.g.
    // plugins: [...options.plugins, myCustomPlugin],
  });
};

Module.prototype.require = function (id) {
  // when remix requires esbuild, it will get our modified build function from above
  if (id === "esbuild") {
    return { ...esbuild, build };
  }
  return originalRequire.apply(this, arguments);
};

Then change your build/dev scripts in package.json to load it before invoking remix:

"build": "NODE_OPTIONS='-r ./esbuild-overrides' remix build",
"dev": "NODE_OPTIONS='-r ./esbuild-overrides' remix watch",

[chaance]

We've discussed this at length in other related issues, but we do not plan on opening up our compiler at the moment. Our usage of esbuild is an implementation detail. If there's anything specific missing that you can't currently do without it, we're happy to consider requests for specific features that could help you avoid digging into our compiler.