@parcel/transformer-css errorRecovery flags configurable from .parcelrc, with clearer errors from watch and build

[bnjmnrsh]

💬 RFC

🔦 Context

The new @parcel/transformer-css errorRecovery flag appears to make it possible for us to modernise our tooling while while we migrate away from dependancies that still include a few IE css hacks. However the flag is not very well documented, and unintuitive to implement.

1. From Parcel's documentation:

   Parcel works out of the box for many projects with zero configuration. But if you want more control, or need to extend or override Parcel’s defaults, you can do so by creating a .parcelrc file in your project.

Perhaps it is possible to set the flag in .parcelrc, and I've just not managed to do it correctly, but at the very least its undocumented. If it is not possible, then this would seem to contradict the current documentation for .parcelrc. I for one, would very much prefer specific config to be kept out of package.json, however it doesn't appear that there is currently a way to pass custom config options to transformers and the like.

2. It seems expected that users would try to pass the --error-recovery flag to watch and build, however it may not be ideal to do so as these tools cover a wide range of operations. However, if the --error-recovery flag was encountered, perhaps a more useful error message could be given to users.

I've already submitted an issue for regarding documentation. But ideally the API would change so that .parcelrc could be used instead.

💻 Examples

As.parcelrc config with hypothetical options object:

{
   "extends": "@parcel/config-default",
   "options": {
       "@parcel/transformer-css": {
           "errorRecovery": true
        }
    }
}

As flag:

 $ npx parcel watch ./assets/style.sass -- error-recovery

 >error:  '--error-recovery' can only be passed directly to `css-cli`, or configured in `.parcelrc` or `package.json` [see docs]

[devongovett]

.parcelrc is only for configuring which parcel plugins will be run. Individual plugins should either place their configs in a separate file (e.g. .babelrc) or in package.json. This has been discussed many times before. The reason for this is basically that it would be very difficult to know how to merge plugin configs when an extends is present. By using separate plugin-specific files, this problem is avoided and left to the individual tools (eg. .babelrc extends mechanism). In addition, this makes configs portable between tools rather than specific to Parcel.

[bnjmnrsh]

Hi @devongovett, thank you for your feedback. Obviously Im a newcomer just coming in, and so am reflecting my on boarding experience with this useful feature.

What I understand you are saying is that 'plugins' which in this case is @parcel/transformer-css should expose its own .rc file, even though in this case it's one of Parcel's own internals?

I obviously don't understand the challenges as well as yourself (or what has been debated before - soz!). But its odd to me that we can pass configuration to @parcel/transformer-css via package.json but not able to pass the same kind of object via .parcelrc, –– to this user, in the end it all just looks like Parcel™ 🤷🏼‍♀️

Is there another route, like creating a custom configuration that could move this flag out of our package.json?

[devongovett]

Let me explain in more detail. Let's say you have a .parcelrc like this:

{
  "extends": "@company/parcel-config",
   "options": {
       "@parcel/transformer-css": {
           "errorRecovery": true
        }
    }
}

and @company/parcel-config has something like this:

{
  "extends": "@parcel/config-default",
   "options": {
       "@parcel/transformer-css": {
           "drafts": {
             "nesting": true
           }
        }
    }
}

It's hard to know in the general case whether these two options objects for @parcel/transform-css should be merged, whether one should override the other, whether options in extended configs should be completely ignored, etc. There is not just one right answer for all types of configuration for all plugins. Therefore, we've opted not to include custom options in .parcelrc, delegating configuration loading to plugins. As I mentioned before, this also means config is not specific to Parcel, so you can move between build tools more easily if needed.

In this case, @parcel/transformer-css has decided to place its config in package.json. There is not currently a separate config file available for it. Since it is now basically a wrapper around Lightning CSS, we could potentially add support for a .lightningcssrc file which could be shared between Parcel and other tools using Lightning CSS, but since the config is quite simple, adding it to package.json doesn't seem like too big a deal.

[bnjmnrsh]

@devongovett Thank you for taking the time to write this up, I believe that I have a better understanding of the challenge the project faced and the hows and whys behind adopting this approach. In my own case, I was trying to avoid having optional config in package.json as I too wanted more portablity, but I agree it doesn't make sense for Lightning CSS to go through the extra effort at this time for this one small (but very useful!) config.

Given what you've said, I can also see my second point re specific warnings rewatch and buildwould be impractical as well.

I'll see if I can contribute to the docs around this, as the feature looks to be fairly static and unlikely to change in the near term.

Thanks again ~