Niklas Mischkulnig

`types` is a target just like `main` or `module`. If what you're asking for is a way to have multiple such targets: no, that's currently not possible. It has to...

You can ignore those. The tests are flakey, as long as one of the integration test jobs passes, you're fine.

@daveverwer That sounds a bit like the situation that https://github.com/parcel-bundler/parcel/pull/6072 fixed. Can you try the latest nightly (`parcel@nightly`)? Also, what do you mean by "save"? Do you change the file...

Another place where `node:*` specifiers aren't handled yet: https://github.com/parcel-bundler/parcel/blob/bb923d69f02612d65bc5f430a1cd2f7b21895252/packages/transformers/js/core/src/fs.rs#L54

The resolver is in https://github.com/parcel-bundler/parcel/blob/v2/packages/utils/node-resolver-core/src/NodeResolver.js, search for `node:` in that file. But I think there's currently no way for a resolver to say "don't bundle this dependency (so `isExcluded: true`),...

Does this resolve everyone's concerns regarding different filenames for the manifest? https://github.com/parcel-bundler/website/pull/1052

I've added this to the JS transformer: `console.log(asset.filePath, {code: code.toString(),compiledCode: compiledCode.toString()});` In the working case: ``` parcel/packages/core/integration-tests/test/integration/_test/index.js { code: "import {foo} from './foo.mjs';\n\noutput = foo;\n", compiledCode: 'import "de38b4627ba73b98:./foo.mjs:esm";\n' + 'output...

I think the problem lies here: > // If one of the symbols imported by the dependency doesn't resolve, then we need the > // exports identifier to fall back...

@ericclemmons Can you provide a reproduction (maybe in a new issue)? In a basic react app, these `$parcel$export` also look different for me, what amplify package versions are you using?...

The reason why only the `babelCore.transform...` functions support `inputSourcemap` is probably that the it isn't actually encoded into the AST nodes's `loc` property but it's just applied to the output...