Use package.json#exports map
#4155
Comments
|
Also, conditional exports could be used while bundling to specify the dist paths. They could replace Example: {
"exports": {
".": {
"require": "./dist/node/index.js",
"import": "./dist/module/index.js",
"browser": "./dist/browser/index.js"
}
}
}Would be the same as: {
"main": "./dist/node/index.js",
"module": "./dist/module/index.js",
"browser": "./dist/browser/index.js",
} |
|
If nodejs/node#32869 lands, this likely should include support for |
|
https://github.com/lukeed/resolve.exports might be useful |
|
This would be actually awesome! I was recently refactoring code and used the "exports" field, and I didn't know parcel didn't support this. |
|
yes i think as a work around i have to peek into the package and import from the global scope :( |
|
Any plan for supporting this? There have been so many changes on the V2 branch that it is hard to track the progress. |
|
At the moment we're focused on blockers for a stable v2 release in the next month or so. This will likely be sometime after that. |
|
As a quick work around, I made this fallback resolver: @kkirbatski/parcel-resolver-require-resolve import { Resolver } from '@parcel/plugin';
export default new Resolver({
async resolve({ filePath }) {
try {
return {
filePath: require.resolve(filePath),
};
} catch (e) {
return null;
}
},
}); |
|
Now that we have Parcel 2, is this on the priority? Solid-js depends on this feature. |
|
Packages like "type": "module",
"exports": "./dist/index.js",So currently you can't import it with Parcel: |
|
Unfortunately |
|
Hey folks, this is very important: basically Parcel cannot use modules which support both common.js and ESM. We're forced to revert and drop support for ESM because of that. |
|
FWIW, I looked into implementing this not long ago, using the library linked above. I couldn't figure out where it should go in the resolution algorithm though. Node has two different algorithms for CommonJS and ESM, but bundlers usually do more interop so we will have to diverge. In addition, there are many different conditions that are possible, and it's not obvious whether it should occur before or after other resolution features like aliases. More research is required to see how other bundlers behave so that we don't fragment the ecosystem even more.
This has been possible for a long time, even without the exports field. The |
|
Vuetify 3, for example, won't work. ( |
|
I found a (manual) workaround to continue using Parcel even with these dependencies: Add an
|
The package I needed this for was swiper. The package.json contained an exports directive for resolving the files of the package. To get parcel to resolve it, I installed my plugin and created a {
"extends": "@parcel/config-default",
"resolvers": [
"...",
"@kkirbatski/parcel-resolver-require-resolve"
]
}
I'm not really familiar with these new mechanisms for resolving packages, but hopefully this helps a little. |
|
This is causing issues with using Preact in the Parcel development server: Preact specifies what The |
|
#8807 implements package exports support, and will be included in the next release soon. |
|
This is now released in nightly. Would be great if you all could try it out in your projects and report back if it is working before the full release! |
Great news! I'll add some comments here if I experience issues with it. I'm not quite sure yet how big of a pain point this will be for us and if it's worth the effort to report this as a proper issue with a reproduction, but one issue that I encountered already is the following: This worked before (on 2.8.3). The setup is the following:
So parcel now has issues resolving workspace packages in workspaces it isn't ran in if that makes sense. |
|
Next issue: @devongovett I'd love to hear from you if this is a supported use case or if I'm just doing illegal stuff here (also contains actual regression: We're publishing a package that exports both TypeScript code and a SCSS module (for styling). It would be really nice to be able to just import the TypeScript stuff as To do that, I've put this in the (I got the inspiration for the Unfortunately though, it doesn't work - parcel tries to import the JavaScript into SCSS instead (it does work on packages though that only export scss): Regression in
|
|
@danieltroger thanks so much for testing! Really great to get feedback from real-world projects – it's really hard to cover all possible project setups in our integration tests so this is very helpful. You have some interesting cases here. The first one looks related to tsconfig. It's trying to find the "../../tsconfig_base" file referenced in the "extends" field from /Users/daniel/Documents/depict.ai/browser-tags-v2/packages/js-ui/tsconfig.json, so /Users/daniel/Documents/depict.ai/browser-tags-v2/tsconfig_base. I think this is perhaps a bug where we need to append The second issue about SASS is because with package.json exports, only files declared in the exports map are allowed to be imported, so where it would previously have resolved to Third issue is the same as the second. Importing directly from |
Yes, the tsconfig error looks like that's probably it.
Not sure, but some tool should because
Why does this not work then? (Unzip, It yields: Why I think this should work:
in its package.json. How would you recommend me solve my sass exporting use case?
Indeed. I think it could break lots of things and there doesn't seem to be a workaround for that breakage other than changing the imported package? |
This is to support another resolver feature, which respects the
Bootstrap uses the top-level "sass" field in package.json it seems: https://github.com/twbs/bootstrap/blob/5241b988c0156dbcc2c6bdaeb29967141bea567d/package.json#L39 I don't see any exports in their package.json. But I do see that
Ah this is using a deprecated syntax in package exports for exporting directories. Node deprecated this syntax in Node 14, and fully removed it in Node 17: https://nodejs.org/api/deprecations.html#DEP0148. I thought since Parcel's support for this is brand new we could get away without supporting it. The new syntax is: See https://nodejs.org/api/packages.html#subpath-patterns.
I think supporting the "sass" export condition is probably the right way. Alternatively you could add
Well, it's a bit of a strange case because most packages on npm would already have had to deal with this if they supported node or other tools like webpack for a while. For internal packages only ever loaded by parcel, package exports were never supported before so it is unlikely that they would have them. |
I see. I tried adding Another thing I had to do was changing the following but now everything works again. Just FYI.Change to fix:diff --git a/storefronts/vanilla-js/babel.config.json b/storefronts/vanilla-js/babel.config.json
index 733ceb3e41..b002b1838a 100644
--- a/storefronts/vanilla-js/babel.config.json
+++ b/storefronts/vanilla-js/babel.config.json
@@ -5,7 +5,7 @@
{
"throwIfNamespace": false,
"runtime": "automatic",
- "importSource": "~/"
+ "importSource": "~"
}
]
]Error message without it:
Yay, that'd be amazing 🎉
Ah, thanks. Thanks a lot for the links to the docs too. What do you think about warning about this? I think that could save people time and pain.
Right, so just On a second thought
Why doesn't work given I'd consider it explicitly declared when it says |
This works, but only when importing |
|
#8844 implements support for the sass, less, stylus, and style conditions supported by webpack. It also opens the door for plugins to support other custom conditions. Note that in your example, "sass" would need to come before the "default" condition for this to work, since default always matches and matching follows the key order in package.json. That PR also fixes the tsconfig extends bug. |
|
I regret to post to a closed issue, but I think the story is not over yet. Apparently, parcel can not correctly resolve |
|
Oh, never mind. It works in nightly. I hope it is released soon enough. |
|
Yes, sorry it's taken longer than expected to get released. We have run into some backward compatibility issues. Unfortunately, I think we are going to have to make exports support opt-in until Parcel 3 as adding it is a breaking change for some packages. Once that is done we can release it soon. |
|
For future reference, here's how to opt-in to this before parcel 3 is released https://parceljs.org/blog/v2-9-0/#new-resolver |
|
Hi everybody, When bundling CommonJS code and one of the dependencies is using using imports field, we'll end up hanging on the following error: New resolver is explicitly enabled in root package.json: "@parcel/resolver-default": {
"packageExports": true
}I've tried to use alias in root package.json, but with no effect: "alias": {
"./node_modules/swagger-ui-react/index.mjs": "./node_modules/swagger-ui-react/index.cjs",
"#swagger-ui": "./node_modules/swagger-ui-react/swagger-ui.js"
}Any idea how to resolve this, or do I need to write my own resolver? Note: when using ESM, everything works as expected. |
|
I’m testing Parcel |
|
Since this is the top search result, here's what you need to enable support for the Add this to your package.json: {
"dependencies": {
// your stuff here
},
"devDependencies": {
// your stuff here
},
"@parcel/resolver-default": {
"packageExports": true
}
} |
|
Oh, and 2 cents from me regarding monorepo. If you use monorepo, |
and others
🙋 feature request
Use
exportsmaps in the resolverhttps://nodejs.org/api/esm.html#esm_package_exports
https://nodejs.org/api/esm.html#esm_conditional_exports
https://webpack.js.org/guides/package-exports/
💻 Examples
https://github.com/preactjs/preact/blob/master/package.json#L11
https://unpkg.com/browse/[email protected]/package.json
Relevant code
The resolver: https://github.com/parcel-bundler/parcel/blob/v2/packages/resolvers/default/src/DefaultResolver.js
which calls: https://github.com/parcel-bundler/parcel/blob/v2/packages/utils/node-resolver-core/src/NodeResolver.js
The text was updated successfully, but these errors were encountered: