fix: restore the types field in the package.json file

[sounisi5011]

TypeScript may not use the "types" import condition.

For example, if the value of the moduleResolution option is "node". In this case, TypeScript uses the types field and the "types" import condition is not used.

So even if the "types" import condition is used, package.json still needs the types field for fallback. Therefore, I have restored the types field that was removed in f724043.

Resolves #26

• I tested this change

  $ pnpm run build && pnpm pack
  $
  $ mkdir test-pr-28 && cd test-pr-28
  $
  $ echo '{}' > ./package.json
  $ echo '{ "compilerOptions": { "moduleResolution": "node", "esModuleInterop": true, "strict": true } }' > ./tsconfig.node.json
  $ echo '{ "compilerOptions": { "moduleResolution": "node16", "esModuleInterop": true, "strict": true } }' > ./tsconfig.node16.json
  $
  $ echo 'console.log(require("used-pm")())' > foo.cjs
  $ echo 'import currentPackageManager from "used-pm"; console.log(currentPackageManager())' > foo.mjs
  $ cp foo.mjs foo.cts
  $ cp foo.mjs foo.mts
  $
  $ npm i typescript ../used-pm-1.0.2.tgz # I am using the npm command by intention. When using pnpm, used-pm 1.0.2 released to npm may be added instead of used-pm-1.0.2.tgz due to global caching
  $
  $ pnpm exec node foo.cjs && pnpm exec node foo.mjs && pnpm exec tsc -p tsconfig.node16.json --noEmit && pnpm exec tsc -p tsconfig.node.json --noEmit

[sounisi5011]

Note
I am not a native English speaker, so I am using the DeepL translator (DeepL Pro) for all English text included in this pull request.

DeepL Pro should have no licensing issues ¹, but please check all the English text included (the commit text when merging) before merging.
Maybe the English text contains some mistakes.

If you feel that adding machine-translated text to this repository is undesirable, feel free to close this pull request and create a new one.
I do not take this as an insult.

Footnotes

1. The problem with using machine translation in OSS is that the translation results may be limited to private use. If the copyright of the translation results belongs to the company providing the machine translation, the user's inclusion of the translation in the OSS may exceed the scope of private use and violate the terms of use of the machine translation and the license of the OSS.

   For example, in the Ubuntu translation project, one person used Google Translate to translate into Japanese, which became a big problem because it violated the Ubuntu license.

   • Google翻訳をオープンソースプロジェクトに使うのはダメなのか？ (Is it bad to use Google Translate for open source projects?)
   • Ubuntu英日翻訳にGoogle翻訳の成果物を突っ込む人物が現れライセンスがなんじゃもんじゃでつらい - Togetter (Someone puts Google Translate results into Ubuntu English-Japanese translation, violating the license, and we're hurting - Togetter / Tweet summarizing service)

   In Wikimedia's opinion, the likelihood of copyright infringement from the use of Google Translate on Wikipedia is "very unlikely".

   • Wikilegal/Copyright for Google Translations - Meta

   In the case of DeepL Pro, the copyright of the translation result belongs to the user.

   7.5 DeepL does not assume any copyrights to the translations made by Customer using the Products. In the event that the translations made by Customer using the Products are deemed to be protected under copyright laws to the benefit of DeepL, DeepL grants to Customer, upon creation of such translations, all exclusive, transferable, sublicensable, worldwide perpetual rights to use the translations without limitation and for any existing or future types of use, including without limitation the right to modify the translations and to create derivative works.
   --- DeepL Terms and Conditions

   Therefore, this problem should not exist.

   However, if you think it is necessary, please rewrite the English text. ↩

[mheob]

LGTM. Thank you very much for your work.