Decide the structure and schema of the manifests

[43081j]

The aim of this repo is to provide a set of manifests we can consume in other tools (e.g. an eslint plugin to suggest these alternatives).

I've pushed a bunch of boilerplate here and at least published to claim the npm name (module-replacements) but nothing is concrete.

@thepassle would you mind taking a look through this?

my thinking was:

• the manifests are available in the repo and npm package as JSON
• there is also a JS module made available which bundles that JSON (to avoid relying on node behaviour at runtime) and will eventually export some helper functions (getReplacement etc)

the build isn't quite right at the min as i would need to figure how to publish "bundled DTS" 🤔

[thepassle]

Looks like a good starting point :)

I think both of your points seem good, its good to have a JSON format, but also have something import-able from JS.

On the format of the schema, I wonder how granular we are/should get? Do we warn on imports for a package alone? E.g.:

import { foo, bar } from 'bloated-module';

Or do we point out specific identifiers from that module? For example, say there's a good native replacement for foo, do we specifically keep track of identifiers and the modules that they're available from? Or is it enough to mark a package as being bloated?

(maybe "bloated" isn't the most diplomatic word here, but just trying to get my point across and I can't think of a better suited/more friendly sounding word to describe it)

[43081j]

i think it depends on the module, but most of the ones i've seen so far are entire modules (e.g. URLSearchParams vs a module for constructing regular query strings)

no doubt there will be some where it is a particular export/symbol though. but i wonder if we should leave those for now and just focus on entire packages (otherwise it gets rather complicated.. maybe)

[JounQin]

Do you know about https://github.com/renovatebot/renovate/blob/main/lib/config/presets/internal/replacements.ts?

[43081j]

i did not!

interesting there's some crossover but not entirely, as we also want to provide native replacements here

i think theirs is a fairly focused subset of what we actually want here. though maybe some collab could happen in future

[43081j]

Closing this since it is pretty settled now 👍