<p dir="auto">I understand that when it comes to property initializers, there might be a need to perform some hocus-pocus with the <code class="notranslate">initializer</code> property, which effectively prevents modifying descriptor's <code class="notranslate">value</code> (it is overwritten by the result of the <code class="notranslate">initializer</code> function in the end).</p>
<p dir="auto">But for plain objects descriptor's <code class="notranslate">value</code> can be left intact. Accessing it by a decorator is currently unnecessarily prevented.</p>
<p dir="auto">Could it be not so? If yes, then I volunteer to create a PR with a fix for that :)</p>
<p dir="auto">Feature request:</p>

<p dir="auto"><a href="https://twitter.com/bradleymeck/status/906572163519578112" rel="nofollow">Recommendation</a> from Node core is to output mjs alongside js files so that the package.json <code class="notranslate">main</code> field can be ambiguous. Since babel only outputs <code class="notranslate">.js</code> files when used with the <code class="notranslate">-d</code> directory flag, it becomes complicated to make this work. I'd like to see an option available to specify the extension the same as with parsing/consuming mjs.</p>
<h3 dir="auto">Current Behavior</h3>


<p dir="auto">This is the most elegant solution I've found so far, which involves building all files into a temporary directory, renaming all the files to mjs, copying them into the <code class="notranslate">dist/node</code> destination, and then removing the temp directory.</p>
<div class="highlight highlight-source-shell notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="&quot;build-node-esm&quot;: &quot;babel lib -d dist/node-es &amp;&amp; rename -v .js .mjs dist/node-es/*.js &amp;&amp; rename -v .js .mjs dist/node-es/**/*.js &amp;&amp; cp -R dist/node-es/* dist/node &amp;&amp; rm -rf dist/node-es&quot;,"><pre class="notranslate"><span class="pl-s"><span class="pl-pds">"</span>build-node-esm<span class="pl-pds">"</span></span>: <span class="pl-s"><span class="pl-pds">"</span>babel lib -d dist/node-es &amp;&amp; rename -v .js .mjs dist/node-es/*.js &amp;&amp; rename -v .js .mjs dist/node-es/**/*.js &amp;&amp; cp -R dist/node-es/* dist/node &amp;&amp; rm -rf dist/node-es<span class="pl-pds">"</span></span>,</pre></div>
<h3 dir="auto">Possible Solution</h3>


<p dir="auto">My suggestion would be to add a new CLI flag option to specify the output extension. This will allow developers to easily support both Node-based ESM/CJS.</p>
<div class="highlight highlight-source-shell notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="babel lib -d dist/node --ext &quot;.mjs&quot;"><pre class="notranslate">babel lib -d dist/node --ext <span class="pl-s"><span class="pl-pds">"</span>.mjs<span class="pl-pds">"</span></span></pre></div>
<h3 dir="auto">Context</h3>


<p dir="auto">I'm trying to figure out how to build a library that will be ready to take advantage of the new Node ESM semantics.</p>
<h3 dir="auto">Your Environment</h3>

<table role="table">
<thead>
<tr>
<th>software</th>
<th>version(s)</th>
</tr>
</thead>
<tbody>
<tr>
<td>node</td>
<td>v9.0.0-pre</td>
</tr>
</tbody>
</table>