Add checks for middleware being used twice unintentionally

[edmorley]

To try and prevent the confusion caused when users do things like:

• using @neutrinojs/react followed by @neutrinojs/web, which clobbers the React parts of the config:
  #1129 (comment)
• using @neutrinojs/react followed by @neutrinojs/style, which causes incorrect extract and hot configuration:
  #1129 (comment)
  #755 (comment)
  #803 (comment)
  #869 (comment)

[timkelty]

using @neutrinojs/react followed by @neutrinojs/style, which causes incorrect extract and hot configuration:

@edmorley there is some crossover here with #964.

I've had a few people asking how they can configure @neutrinojs/style to have separate rules (e.g. one less and one sass), each with different test and loaders.

…and you can't. My only suggestion to them thus far was doing exactly what you're referencing here: use @neutrinojs/style after @neutrinojs/web|react|vue and configure a second separate rule.

[edmorley]

My only suggestion to them thus far was doing exactly what you're referencing here: use @neutrinojs/style after @neutrinojs/web|react|vue and configure a second separate rule.

The check in the PR uses neutrino.config.module.rules.has(options.ruleId), so if I've understood the workaround for #964 correctly, it shouldn't be affected, since people are using a different ruleId (otherwise the rules would have been overwritten anyway).

However perhaps the wording of the error message shown needs to say:
"... Or if using twice is intentional, remember to set a different ruleId" etc?
(I just thought it was implied given the first sentence of the message, but perhaps best to be explicit?)

[timkelty]

@edmorley My only thought is you could consider simplifying the messages and including a link to a page in the docs detailing more specifics – but short of that, looks good!

[edmorley]

Yeah true. I think the reason I didn't initially, is that there isn't a good permalink for many of the settings, since they appear in the middle of "here are all the options" sections. A hardcoded URL would also get out of date once we release new major versions of Neutrino (though we have this problem already in a few places).

[eliperelman]

Another way we could have a more generic error message would be to subclass Error:

class DuplicateRuleError extends Error {
  constructor(name, ruleId) {
    super(
      `${name} has been used twice with the same `ruleId` of ${ruleId}.\n` +
      'If you are including this preset manually to customise the rules\n' +
      "configured by another preset, instead use that preset's own options to do so."
    );
  }
}

// ...

if (neutrino.config.module.rules.has(ruleId)) {
  throw new DuplicateRuleError('@neutrinojs/compile-loader', 'compile');

[edmorley]

Yeah that may be better (I'd decided against it before since each message was subtly different eg the preset option name, but perhaps that's unnecessary). Should DuplicateRuleError live in neutrino?

[eliperelman]

Should DuplicateRuleError live in neutrino?

That would be my recommendation since every middleware we have peer-depends on it.

[edmorley]

PR updated with a new ConfigurationError and DuplicateRuleError