-
-
Notifications
You must be signed in to change notification settings - Fork 184
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multi level "exports" not supported? #250
Comments
Regardless, for backwards compatibility, packages like multiformats should be mimicking the "exports" structure in a CJS-compatible directory structure - at which point, tools like resolve will Just Work. |
After digging a bit deeper this has nothing to do with the That is, you can't use One thing is that the file at the given path doesn't need to actually have any content, it just needs to exist, and node will take |
Browserify [does not support](browserify/resolve#224) `"exports"` in a `package.json`, and nor can you use `"browser"` in `package.json` [as a hint to Browserify to look in a certain place for a file](browserify/resolve#250 (comment)). This means the output of `ipjs` is not compatible with Browserify since it expects the runtime/bundler to use the `"exports"` field to look up files paths. If Browserify finds a file path, it will then use the `"browser"` values to apply any overrides, which `ipjs` uses to direct it to the `/cjs` folder. The problem is if it can't find the file in the first place it won't use the `"browser"` map to get the overrides. Handily we're generating the `"browser"` field values from the `"exports"` values so we know we have the complete set of files that the user wants to expose to the outside world, and the paths we want people to use to access them. The change in this PR is to use the `"browser"` field values to [mimc the `"exports"` structure in a CJS-compatible directory structure](browserify/resolve#250 (comment)) as per @ljharb's suggestion. For any file that we are overriding with `"browser"` values, we create an empty file (where a resolvable file does not already exist) a the path Browserify expects it to be at, then it'll dutifully use the `"browser"` field to pull the actual file in.
New node will, yes, but old node won't use |
Browserify [does not support](browserify/resolve#224) `"exports"` in a `package.json`, and nor can you use `"browser"` in `package.json` [as a hint to Browserify to look in a certain place for a file](browserify/resolve#250 (comment)). This means the output of `ipjs` is not compatible with Browserify since it expects the runtime/bundler to use the `"exports"` field to look up files paths. If Browserify finds a file path, it will then use the `"browser"` values to apply any overrides, which `ipjs` uses to direct it to the `/cjs` folder. The problem is if it can't find the file in the first place it won't use the `"browser"` map to get the overrides. Handily we're generating the `"browser"` field values from the `"exports"` values so we know we have the complete set of files that the user wants to expose to the outside world, and the paths we want people to use to access them. The change in this PR is to use the `"browser"` field values to [mimc the `"exports"` structure in a CJS-compatible directory structure](browserify/resolve#250 (comment)) as per @ljharb's suggestion. For any file that we are overriding with `"browser"` values, we create an empty file (where a resolvable file does not already exist) a the path Browserify expects it to be at, then it'll dutifully use the `"browser"` field to pull the actual file in.
This has been fixed by the linked ipjs PR |
The multiformats module has the following fields in it's
package.json
:and the following directory structure:
When using browserify on a project that depends on multiformats, I see errors when trying to require anything greater than one level deep in the module:
Is this intentional? I can't see where this module consults the
exports
field (though it's been a long day) or is it unsupported?The text was updated successfully, but these errors were encountered: