Phasing out rework engine

Question

Phasing out rework engine

Closed this issue 4 years ago · 13 comments

This issue is a placeholder for discussion about removing rework engine.

The expectation is that most users are or should be on the postcss engine. For these users the additional dependencies of rework are bloat.

Roadmap

v4 the engine option will be deprecated.
v5 the engine option will be removed along with any rework dependencies.

Considerations

Some users are stuck on rework due css compatibility problems with postcss (real or perceived).

The release of v4 should add some long awaited improvements to resolution of url(). The plan as it stands is to ship and stabilise that release and to then make a further major release simply to remove rework engine.

The deprecation warning in the v4 release should prompt those users still stuck on rework to get in contact and we should learn more about what remaining issues they have with postcss.

Interrum options

I am open to externalising rework dependencies for v4 so most users do not need to download it. But only long as there is some simple method that doesn't require restructuring of the package or other large efforts.

Answer 1 · 2020-07-29T08:06:27.000Z

You can use https://yarnpkg.com/configuration/manifest#peerDependenciesMeta. (It's implemented in npm too: https://github.com/npm/cli/blob/latest/CHANGELOG.md#v6110-2019-08-20)

Answer 2 · 2020-08-05T11:15:07.000Z

it would be great if support for rework would be done using an optional peer dependency indeed, so that already removes all the rework dependencies for projects using the postcss engine. It would require to add rework and rework-visit as dependencies of your own project if you want to enable the rework engine, but I think that's fine for a deprecated feature.

this would get rid of deprecation warnings coming from rework dependencies during installs.

Answer 3 · 2020-08-14T22:45:43.000Z

Moved rework and rework-visit to optional peer dependencies in #166.

Hopefully that is fine for the interim. But this issue is still open until v5 release where we completely remove it.

Answer 4 · 2021-02-16T09:59:36.000Z

@bholloway any idea when v4 will be released with this phasing out ?

Answer 5 · 2021-02-25T09:07:18.000Z

I'm hoping to release a new distag @next soon that will have that change. It will still be alpha but I think its close to beta.

Answer 6 · 2021-03-02T10:08:27.000Z

I have just published resolve-url-loader@4.0.0-alpha.3 where rework and rework-visit are optional.

Please try this using dist-tag @next. The more adoption/usage of the alpha the quicker we can move to v4 release.

Answer 7 · 2021-03-02T10:13:40.000Z

Does it have some break changes?

Answer 8 · 2021-03-02T10:20:50.000Z

@yoyo837 check the changelog.md for breaking changes and migration guide.

I now realize I should point to the changelog in the docs.

Answer 9 · 2021-03-02T10:22:05.000Z

Thanks for your job!

Answer 10 · 2021-03-02T10:48:55.000Z

4.0.0-alpha.3:
resolve-url-loader: webpack misconfiguration webpack or the upstream loader did not supply a source-map

3.1.2 is works well.

Answer 11 · 2021-03-02T10:50:55.000Z

@yoyo837 can you please open a new issue please and I will try to help. 🙏

Answer 12 · 2021-03-30T23:16:41.000Z

Released resolve-url-loader@4.0.0-beta.1.

Answer 13 · 2021-05-20T11:44:19.000Z

Since we have released resolve-url-loader@4.0.0 the rework dependencies are now optional and the engine option is deprecated.

I have also just released a V5 alpha as resolve-url-loader@next where rework engine is completely removed and only postcss@8 is used.

I think that is sufficient to close the issue.