Add jsx frag pragma support

[Ailrun]

Resolves #2156.

[ljharb]

The values in "settings" have no need to be the same as the inline jsdoc comment names; why deprecate the nice ones?

[ljharb]

i'm confused, why would this be deprecated?

[Ailrun]

Since semantics changed, I think new settings should be provided (not to break existing settings of current users)
If you think just breaking those (and probably update major version) is better, I will update this PR.

[ljharb]

How have the semantics changed (for users who haven't added the new pragma settings)?

[Ailrun]

I mean, if old users use pragma with React, originally rules will detect <pragma>.createElement. With jsxPragma, rules detect <jsxPragma> so that its behavior aligns with babel's.
Therefore, if I just use pragma and do not add new settings, it will break existing settings.

[ljharb]

Right but why would jsxPragma even exist in the common case for users of this plugin, if it doesn't do anything for them?

[Ailrun]

@ljharb Could you tell me your suggestion for the setting combination?
I don't get the right point I need to explain, so I think that would be easier to me.

[Ailrun]

@ljharb FYI, what I considered are

1. A case with custom element creator. (should use jsxPragma)

   import { jsx } from 'my-jsx';
   import React from 'react';
   
   <><div /></>

2. A case with different local name for React. (should use localName)

   import R from 'react';
   
   <><div /></>

3. A case with different library with Fragment support. (should use jsxFragPragma)

   import O from 'other-jsx-library-supports-fragment';
   
   <><div /></>

4. Cases with mixes of others.

[ljharb]

OK, so. To support your first 3 cases:

1. currently not supported - createElement is hardcoded off of the pragma.
2. currently uses pragma; localName is fine to also support via an inline comment, but pragma should remain the only way to configure this in settings.
3. currently uses fragment in getFragmentFromContext, and then pairs that here with pragma - if jsxFragPragma should override both, then that's fine to support as an inline comment, and maybe we could make the fragment setting be either a string (paired with pragma), or an object where either is supported?
4. without specifics i'm not sure what we need to do here.

It seems like we should maybe do these new features as separate PRs.

The first one seems to be 3 - ie, add support for an alternative schema in fragment, that inline jsxFrag comments hook into.

[ljharb]

similarly, why deprecate this?

[Ailrun]

I don't have enough time to manage this PR, so I close this.

[ljharb]

If it’s ok, I’d prefer to keep it open in case someone else can help by posting a link to a branch (not an additional PR, please)