The current logic in https://github.com/microsoft/DefinitelyTyped-tools/blob/HEAD/packages/dts-gen/src/names.ts#L1 is basically "if it's a scoped package, replace the slash with __".
Unfortunately, this fails in the event of an existing package with a double underscore. I don't have a concrete existing example, so it's not an urgent problem :-) but, eg the types for @eslint/js are in @types/eslint__js, but anyone could make a package eslint__js, and then what would the types package for that be?
Obviously changing existing DT package names would be very disruptive, but if we could come up with, for non-scoped packages that have a double underscore, a new convention, then that'd close this theoretical hole (even if nobody ever needed it).
One idea is eslint__js → eslint____js, eg replace __ with ____. this would mean that eslint____js (4 underscores) would become 8, etc, but the likelihood of this running into package name limits is even lower than the likelihood of 2 underscores being used.
Essentially, any replacement scheme would make __ in a regular package name be transformed into something else, and that would require a similar cascade as above.
The current logic in https://github.com/microsoft/DefinitelyTyped-tools/blob/HEAD/packages/dts-gen/src/names.ts#L1 is basically "if it's a scoped package, replace the slash with
__".Unfortunately, this fails in the event of an existing package with a double underscore. I don't have a concrete existing example, so it's not an urgent problem :-) but, eg the types for
@eslint/jsare in@types/eslint__js, but anyone could make a packageeslint__js, and then what would the types package for that be?Obviously changing existing DT package names would be very disruptive, but if we could come up with, for non-scoped packages that have a double underscore, a new convention, then that'd close this theoretical hole (even if nobody ever needed it).
One idea is
eslint__js→eslint____js, eg replace__with____. this would mean thateslint____js(4 underscores) would become 8, etc, but the likelihood of this running into package name limits is even lower than the likelihood of 2 underscores being used.Essentially, any replacement scheme would make
__in a regular package name be transformed into something else, and that would require a similar cascade as above.