feat: support loading ts config files in esm contexts

[brc-dd]

Notable Changes

Commit Message Summary (CHANGELOG)

support loading ts config files in esm contexts and add support for .cts and .mts files

Type

• Feature

SemVer

• Breaking Change (:label: Major)

Issues

• Fixes TypeScript doesn't work with "type": "module" in package.json #239
• Fixes Add ESM support to typescript config files #246

Checklist

• Lint and unit tests pass with my changes
• I have added tests that prove my fix is effective/works
• I have added necessary documentation (if appropriate)

[ai]

Can you fix test coverage?

[brc-dd]

Updated!

[yunsii]

What a great work, any progress here?

[ai]

@yunsii can you test this branch on big project? If it works, I can try to merge and release it.

[yunsii]

@yunsii can you test this branch on big project? If it works, I can try to merge and release it.

Sure, I can test it, but I use postcss config with simple config, only use plugins option for now. Test coverage is not good enouph to prove it?

[ai]

@yunsii

Sure, I can test it, but I use postcss config with simple config, only use plugins option for now. Test coverage is not good enouph to prove it?

Yes, we do not need more (we just need to be sure that config works in general, anyway different keys parsing is the same for all config types).

[yunsii]

Since it is so, I will try to test in this weekend.

[neoReuters]

So just to confirm,

a postcss.config.ts file with the following configuration:

import type { Config } from 'postcss-load-config';
import tailwindcss from 'tailwindcss';
import autoprefixer from 'autoprefixer';

export default {
  plugins: [
    tailwindcss(),    
    autoprefixer,
  ],
} satisfies Config;

Should work with this fix?

[ai]

@neoReuters as I understand, yes

[brc-dd]

I should also test this once with Deno. I don't think jiti supports that. With Node and Bun it should work fine, but Deno is different story. We can probably bypass the loader in Deno (or probably for everything where native import doesn't throw) 👀

[ai]

@brc-dd can you also rebase PR?

We can merge it when somebody will test it in big production project.

[brc-dd]

Updated the code to lazy load jiti -- use native import and only fallback to jiti if that fails. This enables better support for .postcssrc.ts files in Deno and Bun. But yeah, there can be some hidden issues (like with interop default). I'd suggest to publish a pre-release version like 5.0.0-beta.0, and ask people to use that version (preferably using something like npm/pnpm overrides so we can see how it plays with other tools).

[ai]

I'd suggest to publish a pre-release version like 5.0.0-beta.0, and ask people to use that version (preferably using something like npm/pnpm overrides so we can see how it plays with other tools).

We don’t have enough active followers for that :(

[kingyue737]

Test this PR in my template project kingyue737/vitify-admin#25 and it works (CI failed because I install postcss-load-config from github:brc-dd/postcss-load-config, I don't know how to make it pass in github CI). But I need to rename postcss.config.ts to postcss.config.mts, even though type: module has been set in package.json.

[brc-dd]

Ah, with vite 5 it won't work properly. In vite, we are currently bundling this module with a custom patch.

[ai]

In vite, we are currently bundling this module with a custom patch.

What patches do you use? We can move them to the core?

[ai]

@brc-dd will we be able to use JSON .postcssrc but import there TS ESM plugins like:

{
  "plugins": {
    "./postcss/my-custom-plugin.ts": {}
  }
}

[brc-dd]

What patches do you use? We can move them to the core?

Ah, that's same as fa058dd. But during vite 5 release, that wasn't published (mts / ts esm is still not supported). Also there are some patches for ts-node (need to tell rollup that it's not required at top and don't bundle that) -- those won't make sense in the core. That's why normal pnpm overrides for this module won't work for vite. Similar case for Next.js too, they also patch/bundle this module I guess.

[brc-dd]

Do we need to add some changes?

Yeah, had to move that ts extension test above importing jiti. Updated that now.

[brc-dd]

Supporting ESM (even without TS) will need big refactor - will have to make everything async to use dynamic imports, etc. Do we need that?

I need it in my project :D.

I'll try to create a PR separately. It won't be a breaking change as our exported function is async anyway.

[brc-dd]

@ai Any specific reason for making postcss required peer dep in 75364b4? Initially, it was discussed here I guess - vitejs/vite#7495 (comment)

I'm fine with the change because mostly we already have postcss installed. But curious if there are people using this just to load config and pass it to some other tool and they don't have a direct dependency on postcss, this might gonna start giving warnings on things like yarn berry or pnpm with autoInstallPeers off / or on pnpm@7 or lower

GitHub search results - https://github.com/search?q=/%22postcss-load-config%22/++path:/package%5C.json/++NOT+/%22postcss%22/+NOT+is:fork+NOT+is:archived&type=code

[ai]

Any specific reason for making postcss required peer dep

I removed it because I didn’t find a reason of loading config without having postcss.

If we will have real use case, I will revert change.

[brc-dd]

If we will have real use case

People doing something like this - https://github.com/didi/mand-mobile/blob/4611c9bf5dda15b244a0da768fde20b80cb997b2/build/rollup/rollup-plugin-example-config.js#L37-L56 (passing plugins/options to rollup-plugin-css)

[ai]

People doing something like this

Sure. Reverted.

[ai]

I'll try to create a PR separately. It won't be a breaking change as our exported function is async anyway.

Is it OK if I will wait this PR before the release?

I updated code style. The project is ready for forking again.

[brc-dd]

Is it OK if I will wait this PR before the release?

I'll try to create one by this week 👍

[ai]

Released in 5.0.

[privatenumber]

Would yall be open to supporting tsx as a fallback loader too? Would be less dependencies in projects that use esbuild (e.g. Vite).

[brc-dd]

@privatenumber Does tsx provide a way to require specific files? Or register/unregister loaders in node 18?

[privatenumber]

I'll look into supporting both of those!

[brc-dd]

Also, the way it's currently implemented, it already supports tsx. Like if you run tsx file_that_loads_config.js or node --import tsx file_that_loads_config.js it will work fine even if you don't have jiti installed. Same with anything like tsimp or tsm. But to make it work for node.js without any loader, it'll need something that can require TS on demand.

[privatenumber]

I noticed, but

1. I would prefer not to need to use tsx for running future versions of Vite only for the PostCSS config

2. This is an interesting but valid use-case, and I'd like tsx to be a more versatile utility to handle something like this as well

[brc-dd]

Also, if you're supporting something like importUsingTsx then can you also add dependency tracking? It's not needed for postcss, but many of the projects in vite ecosystem are using hacky way of using vite's loadConfigFromFile for this. There vite is returning esbuild's metafile that has list of deps. For example, in vitepress we use that for loading config, path and data loader files, and need to reload if they or any of their dependent files are changed. In contrast, Nuxt is using jiti, but that doesn't support this and hence if you change any dependent file of config it doesn't trigger reload. You need to manually restart the process.

[karlhorky]

Thanks for the release postcss-load-config@5.0.0 with full ESM support in postcss.config.ts with "type": "module" @brc-dd and @ai 🙌

[brc-dd]

Thanks for the release postcss-load-config@5.0.0 with full ESM support in postcss.config.ts with "type": "module" brc-dd and ai 🙌

Hey man, we understand that you're happy about the added support. But please avoid pinging and posting the same message on each thread. We already have to go through a bunch of notifications on daily basis and these just add noise. Prefer using emoji reactions instead.

[karlhorky]

Understood, I'll try to reduce the pinging and notifications. Sorry.

For background, what I'm aiming to do is make it easier to easily find the exact version that support was added in when visiting this issue from a search engine eg. Google - because this relates to a bug that will probably affect people for some time.

I'll try to find a middle path that still does this but reduces the noise.