Added "./package.json" to "exports" field

[bmeeder22]

📦 Pull Request

When importing to react native an error message is appearing:

warn Package @magic-ext/solana has been ignored because it contains invalid configuration. Reason: Package subpath './package.json' is not defined by "exports" in node_modules/@magic-ext/solana/package.json

Not sure if this is causing any issues but it is best practices to export the package.json if exports are defined.

✅ Fixed Issues

Fixes #272

🚨 Test instructions

Add to a react native android app and make sure the warning doesn't appear.

⚠️ Don't forget to add a semver label!

• patch: Bug Fix

[smithki]

Thanks for you contribution! I can merge this for you, but beforehand we'd need to update package.json files across all packages in the monorepo so we may resolve this issue once and for all. If you don't have the bandwidth for extending your change, we can bring this in-house as well. Let me know!

[smithki]

I see a linter warning coming from VSCode's package.json schema-checker. Not sure if this is actually an issue in practice. Do you have any context @bmeeder22?

The warning disappears when conditional "exports" are not in use. I'm not sure if this is a limitation of the spec, or of the schema reference.

[bmeeder22]

The place that I am seeing warnings is while attempting to use this package in react-native:

yarn run v1.22.17

$ react-native start
warn Package @magic-ext/solana has been ignored because it contains invalid configuration. Reason: Package subpath './package.json' is not defined by "exports" in /Users/.../mobile/node_modules/@magic-ext/solana/package.json

This appears to be unique to react native >= Node V14 as per this issue: react-native-community/cli#1168

[bmeeder22]

Because the warning is in the VS Code linter and not eslint. My guess is that your seeing that error only as part of the VS Code built in linter which might not have the most updated spec.

It appears that this only matters when there are defined exports. In packages without explicitly defined exports everything works just fine.

[bmeeder22]

Another good thing to note that the warning appears to just be a warning initializing the extension is working just fine in the RN application. Hopefully that doesn't change in some later version.

[smithki]

Unfortunately our build system complains about this change with the following warning:

Which leads me to think this is a limitation of the "exports" spec, that conditional exports cannot be mixed at the top-level with path mappings. A format like this works, however:

{
  "exports": {
    "import": {
      ".": "./dist/es/index.mjs",
      "./package.json": "./package.json"
    },
    "require": {
      ".": "./dist/cjs/index.js",
      "./package.json": "./package.json"
    }
  },
}

The problem is that this would require some tinkering with the conventions of our build system, which is pretty risky. We've had issues every single time we've overhauled something in the build system because we have to support so many different platforms, bundlers, and runtimes. Most recently this happened yesterday! (#270). I'd feel more comfortable about approaching a change like this once the Magic team has more cycles. It would be even better if we had some acceptance tests in place beforehand (which is something I'm anticipating for the future).

VSCode complains either way...

---

My personal experience with the "exports" spec is unfortunately limited. It took some serious trial & error to get things working as they are with interoperability across web & React Native. I'm tempted to say this is entering wontfix territory for us, as React Native functionality is ultimately unaffected (besides a noisy warning).

If someone wanted to consume a Magic JS package.json file, they could do so with fs.readFile or similar. In a bundling scenario, if it truly is necessary, then the JSON contents could be read at build time and added to an ENV variable in the bundle (in fact, we do something similar here in this repo to read the SDK version at build time).

[smithki]

Closed as wontfix in the short-term. Though I greatly appreciate your efforts, @bmeeder22!