postcss / postcss-load-config

Autoload Config for PostCSS
MIT License
638 stars 71 forks source link

feat: support `postcss.config.ts` #218

Closed G-Rath closed 3 years ago

G-Rath commented 3 years ago

Notable Changes

This lands support for postcss.config.ts ๐ŸŽ‰

Commit Message Summary (CHANGELOG)

feat: support `postcss.config.ts`

Type

SemVer

Issues

Checklist

G-Rath commented 3 years ago

The types should be mostly correct, but plugins & other dependencies require some upstream updates to be v8 compatiable i.e. https://github.com/DefinitelyTyped/DefinitelyTyped/pull/53003

ai commented 3 years ago

Thanks. Looks great.

But can I also ask you to add ESM export test for postcss.config.ts with "module": "esnext" in tsconfig.json?

G-Rath commented 3 years ago

@ai I can do an approximation of that, but it won't be completely possible without upgrading jest and configuring module support (i.e you need to run node with --experimental-vm-modules) since using esnext means that the test suite has to be able to use import/export.

I can implement the use of interopRequireDefault which should be the key thing required to provide nice support for both modules & commonjs.

ai commented 3 years ago

Yeap, you can update Jest and change how we run tests

G-Rath commented 3 years ago

I don't think this is possible without making a breaking change, as you have to set "type": "module" in the root package.json, which means require cannot be used anywhere (not to mention iirc this impacts downstream users on the module).

I'm happy to explore this, but think it would be better to land support for this as is (as that matches how other libraries like jest, webpack, karma, ajv, etc are supporting it), and then look at refactoring the codebase for native ESM support as a follow up.

ai commented 3 years ago

I asked this, because I'm afraid that ts-node is a bad solution.

A few months ago, there was no way to use ts-node with ESM in TS. If it is still a problem, can we switch to another method?

G-Rath commented 3 years ago

I'm afraid that ts-node is a bad solution.

Is that a statement or a concern? My experience with ts-node so far (which includes my using it to implement support for configs written in TypeScript for a number of tools) has been pleasant and I don't know of any other solution that's as light weight or universal (i.e you could do it with babel, but that's a huge dependency to have for this feature; you could also probably do it with something like esbuild, but then that means you're pulling in binaries that have OS requirements as well as not having type-checking).

My understanding is that ESM is now supported at a similar level to Node.

I can confirm I've been able to create a project with module set to esnext which ts-node is able to correctly execute.

ai commented 3 years ago

Great news. Yeap, letโ€™s do it this way (I will need a day to merge and release it).

ai commented 3 years ago

I will play with ts-node and ESM support on my hobby project first. I hope to release it next week.

G-Rath commented 3 years ago

Awesome - let me know if there's anything I can help with :)

ai commented 3 years ago

Sorry, for the delay. I am back to review the PR.

ai commented 3 years ago

LGTM. Hope to merge and release it tomorrow (sorry, I am moving from one country to another, donโ€™t have a lot of time for open source this month).

ai commented 3 years ago

Thanks. Released in 3.1.