Output format of default target not respected

[vwkd]

🐛 bug report

Specifying the output format of the target "default" in the package.json has no effect. It works fine with any other target name.

EDIT: No, actually only the target name "module". It doesn't seem to work with any other target name. Another bug?

🎛 Configuration (.babelrc, package.json, cli command)

package.json

"targets": {
    "default": {
      "engines": {
        "outputFormat": "esmodule"
      }
    }
  }

🤔 Expected Behavior

The file is an ES module.

😯 Current Behavior

The file is an IIFE, as produced by the default output format global.

💁 Possible Solution

A workaround is to use the target name "module". But then it uses that target name as subdirectory of the output directory. To actually use the default output directory of the "default" target, one has to set the distDir explicitly. This is cumbersome. It would be easier if we could just overwrite the output format of the default target.

So, in other words, the package.json could look like this

"targets": {
    "module": {
      "distDir": "./dist",
      "engines": {
        "outputFormat": "esmodule"
      }
    }
  }

EDIT 2: Actually this still uses the output subdirectory "module", so the distDir is somehow not applied for the target name "module". Yet another bug?

🔦 Context

I want to bundle up some Elm code into an ES module.

💻 Code Sample

🌍 Your Environment

Software	Version(s)
Parcel	2.0.0-rc.0
Node	v16.6.0
npm	7.19.1
Operating System	macOS 11.5.2

[mischnic]

It should be

  "targets": {
    "default": {
      "outputFormat": "esmodule"
    }
  }

[vwkd]

@mischnic Thanks. But this doesn't seem to work. It still outputs as "global".

What does work is changing the target name. I just added it into the "Possible Solutions" section.

[mischnic]

Are you sure? The outputFormat config in your "Possible Solutions" example is still wrong

[vwkd]

@mischnic Weird. I was sure I read that somewhere.

I tested it more, and the ES module is correctly exported using either

"targets": {
    "module": {
      "outputFormat": "esmodule"
    }
  }

or

"targets": {
    "module": {
      "engines": {
        "outputFormat": "esmodule"
      }
    }
  }

but neither using

"targets": {
    "default": {
      "outputFormat": "esmodule"
    }
  }

nor

"targets": {
    "default": {
      "engines": {
        "outputFormat": "esmodule"
      }
    }
  }

EDIT: It doesn't actually work with any target name "foobar" but has to be "module". Another bug?
EDIT2: The output directory distDir is actually not applied when using the target name "module". Yet another bug?

[mischnic]

This is just ignored:

      "engines": {
        "outputFormat": "esmodule"
      }

2. The "module" target has "outputFormat": "esmodule" set by default.

3. If you have

"module": "build/index.js",
"targets": {
	"module": {
		"distDir": "dist"
	}
}

then build/index.js will override the distDir setting.

[vwkd]

@mischnic

All the issues still appear when the "engines" is not present, like for example

"targets": {
    "foobar": {
      "outputFormat": "esmodule"
    }
  }

outputs an IIFE.

I count 3 bugs here. I clarified them in my post.

[mischnic]

so the distDir is somehow not applied for the target name "module". Yet another bug?

This is indeed a bug.

---

This is working correctly for me:

  "targets": {
    "default": {
      "outputFormat": "esmodule",
      "isLibrary": true
    }
  },

[thien-do]

@mischnic I reproduced and filed a bug for the distDir issue: #6756 hope it helps :D

[mr-josh]

There's an object defining Common targets in TargetRequst.js which seems to ignore certain settings, including distDir. I don't think it matches exactly the issue going on with #6756 but it might relate. Towards the end of the same file, there's a row statement with a bad docs redirect here.
When commenting out the module key from the COMMON_TARGETS, it still doesn't retain the outputFormat and switches back to global instead of using esmodules.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs.