profile
viewpoint
Geoffrey Booth GeoffreyBooth Walt Disney Imagineering Los Angeles, CA https://geoffreybooth.com Development team lead. Full-stack web developer. Core collaborator of Node.js. Maintainer of CoffeeScript. Imagineer. Father.

aponxi/sublime-better-coffeescript 443

Syntax highlighting and checking, commands, shortcuts, snippets, watched compilation and more.

coffeescript6/discuss 165

A place to discuss the future of CoffeeScript

disney/dockerized-opentext-media-management 12

Scripts and configuration files for running OpenText Media Management in Docker

GeoffreyBooth/browser-equivalence-edge-case 4

A demonstration of code that executes differently in Node and browsers

GeoffreyBooth/coffeescript 4

Unfancy JavaScript

GeoffreyBooth/dual-package-hazard 1

Example illustrating the hazard posed by dual CommonJS/ES module packages

GeoffreyBooth/js-mjs-mime-type-test 1

Test popular webservers’ serving of .js and .mjs files with the correct MIME types

akfish/CommonMark 0

CommonMark spec, with reference implementations in C and JavaScript

cosmicexplorer/coffeescript 0

Unfancy JavaScript

Pull request review commentnodejs/node

esm: fix annotations on getFormat hook doc snippet

 a URL should be interpreted. This can be one of the following: ```js /**  * @param {string} url- * @param {object} context (currently empty)- * @param {function} defaultGetFormat- * @returns {object} response- * @returns {string} response.format+ * @param {Object} context (currently empty)+ * @param {Function} defaultGetFormat+ * @returns {Promise<{ format: string }>}  */ export async function getFormat(url, context, defaultGetFormat) {-  if (someCondition) {+  if (Math.random() > 0.5) { // Some condition.     // For some or all URLs, do some custom logic for determining format.     // Always return an object of the form {format: <string>}, where the     // format is one of the strings in the table above.     return {-      format: 'module'+      format: 'module',

I'm pretty sure our linter doesn't like trailing commas.

DerekNonGeneric

comment created time in an hour

push eventGeoffreyBooth/coffeescript

Julian Rosse

commit sha 75d376f2eff7108ea8bb91d4326aac62989c8556

Fix: comprehension as postfix conditional (#5310) Co-authored-by: Geoffrey Booth <webmaster@geoffreybooth.com>

view details

Geoffrey Booth

commit sha 7e6973c349304a84a4e75d2e0172c329a12888c6

Make browser tests run in headless Chrome

view details

push time in 14 hours

issue closedjashkenas/coffeescript

Bug: DOM manipulation can cause unexpected behavior when executed (specifically a TypeError)

Given the following DOM:

<button id="killer">Kill them what goes.</button>
<div class="stays">
  <div class="goes">one</div>
  <div class="goes">two</div>
  <div class="goes">three</div>
  <div class="goes">four</div>
  <div class="goes">five</div>
</div>

and a document ready handler:

$ ->
  s = new ShowTheBug()
  $('#killer').on 'click', () -> s.killThem()

calling node.removeChild() on all values in a comprehension,

class @ShowTheBug
  killThem: () ->
    @removeChild(c) for c in document.getElementsByClassName('goes')

  removeChild: (c) ->
    p = c.parentNode # throws an exception
    p.removeChild(c)

Expected Behavior

I expected all children of <div class="stays"> to be removed.

Current Behavior

Because the above code compiles thus:

(function() {
  this.ShowTheBug = (function() {
    function ShowTheBug() {}

    ShowTheBug.prototype.killThem = function() {
      var c, i, len, ref, results;
      ref = document.getElementsByClassName('goes');
      results = [];
      for (i = 0, len = ref.length; i < len; i++) {
        c = ref[i];
        results.push(this.removeChild(c));
      }
      return results;
    };

    ShowTheBug.prototype.removeChild = function(c) {
      var p;
      p = c.parentNode;
      return p.removeChild(c);
    };

    return ShowTheBug;

  })();

}).call(this);

eventually the call to this.removeChild(c) fails, because the values in the array ref[] cease to exist once removed, thus shortening the array's length. So, given the example above, once three elements of the array have been removed, the next value for i is 3, ref[3] is outside the bounds of the existing array, and the TypeError: c is undefined is thrown.

Possible Solution

I think this is something CoffeeScript should be aware of in one way or another, but I can't see polluting the compiler with tests for DOM manipulations. The only thing I can imagine that might fix this is to make walking through the values generated in a comprehension in reverse order (ni, perhaps?) a thing that can be done.

Context

I'm trying to manage values sent in an AJAX call, and I add, through events, temporary, hidden inputs to a part of my form. When the send event fires, those values are read and sent along, and the the DOM is scrubbed of the values (in case they need to be generated again).

I have a work-around, so if this isn't something you feel like supporting, I will understand. I can even think of a second work-around that builds an invisible container in the DOM in the first place, and then deletes the container. Nevertheless, this seems worth knowing about.

  • CoffeeScript version: 2.4.1

closed time in 17 hours

derrelldurrett

issue commentjashkenas/coffeescript

Bug: DOM manipulation can cause unexpected behavior when executed (specifically a TypeError)

I think it's a general thing in JavaScript that if you have a comprehension, and the code you're evaluating modifies the thing you're iterating over while you're iterating over it, unexpected results may happen. For example consider Array.prototype.map: its signature is map(element, index, elements). Within that callback could definitely modify elements to remove an element, and then you might not get what you want when it's done. That's not really a bug in map, it's just user error.

derrelldurrett

comment created time in 17 hours

pull request commentnodejs/node

module: remove dynamicInstantiate loader hook

I'd like to land this, so that the community doesn't start to rely on a hook we all seem to agree should be removed. @bmeck @devsnek @guybedford, none of you have blocked this though you've all expressed concerns; can this PR land or should it be blocked?

I understand that generally you all want improvements made to the loaders, and I agree with those sentiments. I think though that in the short term it's best to land this PR, and make an issue or issues to track what improvements we want. Would that work for everyone? There's already https://github.com/nodejs/modules/projects/8, so maybe you can add issues in that repo for what enhancements you want and then add those issues to that board?

jkrems

comment created time in 20 hours

PR closed nodejs/node

esm: merge esm and cjs package.json caches ES Modules

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md --> Relates to: #30674

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

  • [x] make -j4 test (UNIX), or vcbuild test (Windows) passes
  • [x] tests and/or benchmarks are included
  • [x] commit message follows commit guidelines

<!-- Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -->

+119 -67

10 comments

10 changed files

shackijj

pr closed time in 20 hours

pull request commentnodejs/node

esm: merge esm and cjs package.json caches

Landed in 8f10bb2da5bc.

shackijj

comment created time in 20 hours

push eventnodejs/node

Kirill Shatskiy

commit sha 8f10bb2da5bcf166fa1b414055f03352bbdb8126

esm: share package.json cache between ESM and CJS loaders Refs: https://github.com/nodejs/node/issues/30674 PR-URL: https://github.com/nodejs/node/pull/33229 Reviewed-By: Guy Bedford <guybedford@gmail.com> Reviewed-By: Geoffrey Booth <webmaster@geoffreybooth.com>

view details

push time in 20 hours

pull request commentnodejs/node

esm: merge esm and cjs package.json caches

https://ci.nodejs.org/job/node-test-pull-request/31456/ is green, this can land.

shackijj

comment created time in 2 days

issue commentnodejs/modules

Loader Hooks

the problem with unifying the hooks is that require() must be synchronous.

Hmmmm. That is a problem. @jkrems or @weswigham is there any hope here, or would hooks that work with CommonJS run into the same issues that Wes’ “require of ESM” PR did?

I suppose one could write synchronous hooks? CoffeeScript transpilation is synchronous, for example; I dunno if TypeScript’s is? Obviously there couldn’t be a sync HTTP loader but there are plenty of useful loader cases that don’t need async.

Anyway applying these hooks to CommonJS as well is a long-term maybe goal. AFAIK CommonJS wasn’t designed to be hookable/customizable, and the current ways people do it are monkey-patched hacks more or less. Perhaps it’s best left as is.

reasonablytall

comment created time in 2 days

issue commenthelixbass/eslint-plugin-coffee

Using eslint-plugin-coffee with SublimeText: it was easy!

This would be good to add to the README.

PatrickKing

comment created time in 2 days

pull request commentnodejs/node

[WIP] src,lib: policy permissions

I'm also more of a fan of the approach Guy mentioned

This also strikes me as a great benefit of Node over Deno, in that we do have packages and package scopes. A common scenario that I can imagine myself taking advantage of is to somehow configure Node such that my app has full permissions, but packages have no write or network access. In other words, I trust my code, and Node builtins, but not third-party code. In Node we do have the concept of the boundary between application code and third-party code, so we should take advantage of it.

jasnell

comment created time in 3 days

delete branch nodejs/node

delete branch : self-resolve-doc

delete time in 3 days

PR closed nodejs/node

docs: CommonJS self-resolve spec correction doc module

The package self-resolution spec in the CJS docs effectively has an editorial correction here. If this was followed to the word any package.json with "exports" would never be able to load a dependency from node_modules :)

This updates the spec to match what is implemented and what the intent of the spec was.

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

  • [x] make -j4 test (UNIX), or vcbuild test (Windows) passes
  • [x] tests and/or benchmarks are included
  • [x] documentation is changed or added
  • [x] commit message follows commit guidelines

<!-- Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -->

+3 -3

3 comments

1 changed file

guybedford

pr closed time in 3 days

pull request commentnodejs/node

docs: CommonJS self-resolve spec correction

Landed in e88d098e5083

guybedford

comment created time in 3 days

push eventnodejs/node

Guy Bedford

commit sha e88d098e5083329c5afdd6bf66f69c448b9f9be2

doc: correct CommonJS self-resolve spec PR-URL: https://github.com/nodejs/node/pull/33391 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Geoffrey Booth <webmaster@geoffreybooth.com>

view details

push time in 3 days

issue commentnodejs/modules

Executing loader hook functions

One question it looks like I can't add PR's from nodejs/node to that project?

Hmm. Maybe just make issues here that are nothing more than links to the PRs?

coreyfarrell

comment created time in 3 days

delete branch GeoffreyBooth/scrape-script-type-module

delete branch : dependabot/npm_and_yarn/https-proxy-agent-2.2.4

delete time in 3 days

push eventGeoffreyBooth/scrape-script-type-module

dependabot[bot]

commit sha f1b90c93850ee0f4c81dcfce14ef5a23fd05f0ab

Bump https-proxy-agent from 2.2.1 to 2.2.4 Bumps [https-proxy-agent](https://github.com/TooTallNate/node-https-proxy-agent) from 2.2.1 to 2.2.4. - [Release notes](https://github.com/TooTallNate/node-https-proxy-agent/releases) - [Commits](https://github.com/TooTallNate/node-https-proxy-agent/compare/2.2.1...2.2.4) Signed-off-by: dependabot[bot] <support@github.com>

view details

Geoffrey Booth

commit sha 641a5b008b9b29aa4fedc451f34879fceb6b1e87

Merge pull request #2 from GeoffreyBooth/dependabot/npm_and_yarn/https-proxy-agent-2.2.4

view details

push time in 3 days

PR merged GeoffreyBooth/scrape-script-type-module

Bump https-proxy-agent from 2.2.1 to 2.2.4 dependencies

Bumps https-proxy-agent from 2.2.1 to 2.2.4. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/TooTallNate/node-https-proxy-agent/releases">https-proxy-agent's releases</a>.</em></p> <blockquote> <h2>2.2.4</h2> <h3>Patches</h3> <ul> <li>Add <code>.editorconfig</code> file: a0d4a20458498fc31e5721471bd2b655e992d44b</li> <li>Add <code>.eslintrc.js</code> file: eecea74a1db1c943eaa4f667a561fd47c33da897</li> <li>Use a <code>net.Socket</code> instead of a plain <code>EventEmitter</code> for replaying proxy errors: <a href="https://github-redirect.dependabot.com/TooTallNate/node-https-proxy-agent/issues/83">#83</a></li> <li>Remove unused <code>stream</code> module: 9fdcd47bd813e9979ee57920c69e2ee2e0683cd4</li> </ul> <h3>Credits</h3> <p>Huge thanks to <a href="https://github.com/lpinca">@lpinca</a> for helping!</p> <h2>2.2.3</h2> <h3>Patches</h3> <ul> <li>Update README with actual <code>secureProxy</code> behavior: <a href="https://github-redirect.dependabot.com/TooTallNate/node-https-proxy-agent/issues/65">#65</a></li> <li>Update <code>proxy</code> to v1.0.0: d0e3c18079119057b05582cb72d4fda21dfc2546</li> <li>Remove unreachable code: 46aad0988b471f042856436cf3192b0e09e36fe6</li> <li>Test on Node.js 10 and 12: 3535951e482ea52af4888938f59649ed92e81b2b</li> <li>Fix compatibility with Node.js >= 10.0.0: <a href="https://github-redirect.dependabot.com/TooTallNate/node-https-proxy-agent/issues/73">#73</a></li> <li>Use an <code>EventEmitter</code> to replay failed proxy connect HTTP requests: <a href="https://github-redirect.dependabot.com/TooTallNate/node-https-proxy-agent/issues/77">#77</a></li> </ul> <h3>Credits</h3> <p>Huge thanks to <a href="https://github.com/stoically">@stoically</a>, <a href="https://github.com/lpinca">@lpinca</a>, and <a href="https://github.com/zkochan">@zkochan</a> for helping!</p> <h2>2.2.2</h2> <h3>Patches</h3> <ul> <li>Remove <code>package-lock.json</code>: c881009b9873707f5c4a0e9c277dde588e1139c7</li> <li>Ignore test directory, History.md and .travis.yml when creating npm package. Fixes <a href="https://github-redirect.dependabot.com/TooTallNate/node-https-proxy-agent/issues/42">#42</a>: <a href="https://github-redirect.dependabot.com/TooTallNate/node-https-proxy-agent/issues/45">#45</a></li> <li>Update <code>agent-base</code> to v4.2: <a href="https://github-redirect.dependabot.com/TooTallNate/node-https-proxy-agent/issues/50">#50</a></li> <li>Add TypeScript type definitions: <a href="https://github-redirect.dependabot.com/TooTallNate/node-https-proxy-agent/issues/66">#66</a></li> <li>Feat(typescript): Allow input to be options or string: <a href="https://github-redirect.dependabot.com/TooTallNate/node-https-proxy-agent/issues/68">#68</a></li> <li>Update <code>agent-base</code> to v4.3: <a href="https://github-redirect.dependabot.com/TooTallNate/node-https-proxy-agent/issues/69">#69</a></li> </ul> <h3>Credits</h3> <p>Huge thanks to <a href="https://github.com/marco-c">@marco-c</a>, <a href="https://github.com/tareqhs">@tareqhs</a>, <a href="https://github.com/ianhowe76">@ianhowe76</a>, and <a href="https://github.com/BYK">@BYK</a> for helping!</p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/TooTallNate/node-https-proxy-agent/commit/4c4cce8cb60fd3ac6171e4428f972698eb49f45a"><code>4c4cce8</code></a> 2.2.4</li> <li><a href="https://github.com/TooTallNate/node-https-proxy-agent/commit/9fdcd47bd813e9979ee57920c69e2ee2e0683cd4"><code>9fdcd47</code></a> Remove unused <code>stream</code> module</li> <li><a href="https://github.com/TooTallNate/node-https-proxy-agent/commit/34ea8841922fb6447563b0521f972ac3a6062303"><code>34ea884</code></a> Use a <code>net.Socket</code> instead of a plain <code>EventEmitter</code> for replaying proxy erro...</li> <li><a href="https://github.com/TooTallNate/node-https-proxy-agent/commit/4296770b6a0e631e3f8e7bd6cfd41ac8e91a3ec4"><code>4296770</code></a> Prettier</li> <li><a href="https://github.com/TooTallNate/node-https-proxy-agent/commit/eecea74a1db1c943eaa4f667a561fd47c33da897"><code>eecea74</code></a> Add <code>.eslintrc.js</code> file</li> <li><a href="https://github.com/TooTallNate/node-https-proxy-agent/commit/a0d4a20458498fc31e5721471bd2b655e992d44b"><code>a0d4a20</code></a> Add <code>.editorconfig</code> file</li> <li><a href="https://github.com/TooTallNate/node-https-proxy-agent/commit/0d8e8bfe8b12e6ffe79a39eb93068cdf64c17e78"><code>0d8e8bf</code></a> 2.2.3</li> <li><a href="https://github.com/TooTallNate/node-https-proxy-agent/commit/850b8359b7d0467d721705106b58f4c7cfb937dd"><code>850b835</code></a> Revert "Use Mocha 5 for Node 4 support"</li> <li><a href="https://github.com/TooTallNate/node-https-proxy-agent/commit/f5f56fa48ea4d2a61c385938e7753f5c1fe049d6"><code>f5f56fa</code></a> Remove Node 4 from Travis</li> <li><a href="https://github.com/TooTallNate/node-https-proxy-agent/commit/bb837b984bd868ad69080812eb8eab01181b21d7"><code>bb837b9</code></a> Revert "Remove Node 4 from Travis"</li> <li>Additional commits viewable in <a href="https://github.com/TooTallNate/node-https-proxy-agent/compare/2.2.1...2.2.4">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+12 -12

0 comment

1 changed file

dependabot[bot]

pr closed time in 3 days

pull request commentnodejs/node

doc: merge CJS and ESM docs

Thanks for doing this. Because the diff is huge, and GitHub doesn't make clear what text was simply moved as opposed to moved and modified, do you mind listing which sections in the new modules.md were unedited moves from esm.md and which had changes? I assume most will be the former.

aduh95

comment created time in 3 days

push eventnodejs/node

Geoffrey Booth

commit sha 51af89fe453738262e2c10c831705a385ec78530

module: fix check for package.json at volume root Fix package.json files at the volume root so that when they contain {"type": "module"}, they behave as documented, like such a package.json file in any other folder. Fixes: https://github.com/nodejs/node/issues/33438 PR-URL: https://github.com/nodejs/node/pull/33476 Reviewed-By: Guy Bedford <guybedford@gmail.com> Reviewed-By: Jan Krems <jan.krems@gmail.com>

view details

push time in 4 days

pull request commentnodejs/node

module: fix check for package.json at volume root

Landed in a94a5ba7c355819795f3bc4d2d64b011c062fbaf.

GeoffreyBooth

comment created time in 4 days

delete branch GeoffreyBooth/node

delete branch : fix-package-json-type-at-root

delete time in 4 days

PR merged nodejs/node

module: fix check for package.json at volume root ES Modules

Fixes https://github.com/nodejs/node/issues/33438. A package.json at the volume root containing "type": "module" now behaves as documented. Thanks to @vitalets for pinpointing exactly where the problem was.

No idea how to write a test for this, but I tested it manually and this fixes the issue.

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

  • [x] make -j4 test (UNIX), or vcbuild test (Windows) passes
  • [ ] tests and/or benchmarks are included
  • [x] commit message follows commit guidelines

cc @nodejs/modules-active-members

<!-- Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -->

+4 -2

6 comments

1 changed file

GeoffreyBooth

pr closed time in 4 days

issue closednodejs/node

[ES modules] package.json located in root path can't be resolved when checking `type` field

  • Version: v14.2.0
  • Platform: Linux c89b7c439bd7 4.19.76-linuxkit #1 SMP Fri Apr 3 15:53:26 UTC 2020 x86_64 Linux

What steps will reproduce the bug?

Create docker image that generates package.json and index.js in root of filesystem:

FROM node:14-alpine

RUN echo '{ "type": "module" }' > package.json
RUN echo 'import fs from "fs";' > index.js

CMD ["node", "index.js"]

Build and run the container:

docker build -t app .
docker run --rm app

Output:

(node:1) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
(Use `node --trace-warnings ...` to show where the warning was created)
/index.js:1
import fs from "fs";
^^^^^^

SyntaxError: Cannot use import statement outside a module
    at Object.compileFunction (vm.js:344:18)
    at wrapSafe (internal/modules/cjs/loader.js:1106:15)
    at Module._compile (internal/modules/cjs/loader.js:1140:27)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1196:10)
    at Module.load (internal/modules/cjs/loader.js:1040:32)
    at Function.Module._load (internal/modules/cjs/loader.js:929:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
    at internal/main/run_main_module.js:17:47

How often does it reproduce? Is there a required condition?

Always.

What is the expected behavior?

index.js should be loaded as es module because the nearest package.json has "type": "module" field.

What do you see instead?

index.js is being loaded as commonjs.

Additional information

If package.json and index.js are generated in some subdirectory - everything works. You can check it with the following image:

FROM node:14-alpine

# add workdir to generate files in /app not in /
WORKDIR app 

RUN echo '{ "type": "module" }' > package.json
RUN echo 'import fs from "fs";' > index.js

CMD ["node", "index.js"]

The reason of such behavior is this line:

(separatorIndex = checkPath.lastIndexOf(path.sep)) > rootSeparatorIndex

When checkPath = '/index.js', both separatorIndex and rootSeparatorIndex are equals to 0 and condition does not pass.

closed time in 4 days

vitalets

push eventnodejs/node

Geoffrey Booth

commit sha a94a5ba7c355819795f3bc4d2d64b011c062fbaf

module: fix check for package.json at volume root

view details

push time in 4 days

push eventGeoffreyBooth/node

delvedor

commit sha daa65fba7d413691d55051457993405457fa2f41

http: added scheduling option to http agent In some cases, it is preferable to use a lifo scheduling strategy for the free sockets instead of default one, which is fifo. This commit introduces a scheduling option to add the ability to choose which strategy best fits your needs. PR-URL: https://github.com/nodejs/node/pull/33278 Reviewed-By: Robert Nagy <ronagy@icloud.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>

view details

Daniel Bevenius

commit sha ff016fbd8391883a6bb43d0a661d1baafa33ce86

lib: update executionAsyncId/triggerAsyncId comment This commit updates the comment referring to the executionAsyncId/triggerAsyncId pair being stored in a std::stack. It looks like this was changed from std::stack to AliasedFloat64Array in Commit 83e5215a4e8438a43b9f0002b7a43e2fd2dd37a4 ("async_hooks: use typed array stack as fast path"). PR-URL: https://github.com/nodejs/node/pull/33396 Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

view details

Ruben Bridgewater

commit sha 3a5158878b910a9e2d61988ef82640db2a50c0ec

util: mark classes while inspecting them This outlines the basic class setup when inspecting a class. Signed-off-by: Ruben Bridgewater <ruben@bridgewater.de> PR-URL: https://github.com/nodejs/node/pull/32332 Fixes: https://github.com/nodejs/node/issues/32270 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>

view details

Pranshu Srivastava

commit sha 08308c7111b8accc77092999ad4c8fb63807c1f4

http2: do not modify explicity set date headers Fixes: https://github.com/nodejs/node/issues/30894 Refs: https://github.com/nodejs/node/issues/29829 PR-URL: https://github.com/nodejs/node/pull/33160 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>

view details

rickyes

commit sha 1a12b82396c6c0747f8f5c96a28d019f774e0257

fs: refactor the import of internalUtil PR-URL: https://github.com/nodejs/node/pull/33296 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Zeyu Yang <himself65@outlook.com>

view details

Jan Krems

commit sha 6961c7f804cad26b471d5f7c4c92b0861ba19f12

deps: update node-inspect to v2.0.0 Highlights: * Remove use of `process.binding` on modern node (@addaleax) * Increase timeout for port checking (@yilmazdurmaz) * Auto-resume on start when `NODE_INSPECT_RESUME_ON_START` is set (@dolsem) Compare: https://github.com/nodejs/node-inspect/compare/v1.11.6...v2.0.0 PR-URL: https://github.com/nodejs/node/pull/33447 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Matheus Marchini <mat@mmarchini.me> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>

view details

Anna Henningsen

commit sha d2a6f06dce724d24b0aa3c7a2821e4757002bffc

worker: use _writev in internal communication PR-URL: https://github.com/nodejs/node/pull/33454 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

view details

Daniel Bevenius

commit sha 37b4717728413e174ae3d295c74a5b443ca0d901

src: remove unnecessary else in base_object-inl.h This commit removes two unnecessary else statements in base_object-inl.h. It also tries to make the if statements consistent with regards to braces. PR-URL: https://github.com/nodejs/node/pull/33413 Reviewed-By: Zeyu Yang <himself65@outlook.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>

view details

Shelley Vohr

commit sha 81216a349d902dfef94878de75a6fe7ed1c90d1c

doc: claim ABI version 85 for Electron 11 PR-URL: https://github.com/nodejs/node/pull/33375 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Jiawen Geng <technicalcute@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

view details

Michael Dawson

commit sha 4c4c22635927d88eccab495b34564439dbdf50c7

src: prefer make_unique In most of the code base we use make_unique instead of new unique_ptr. Update node_platform.cc to be consistent with that. Signed-off-by: Michael Dawson <michael_dawson@ca.ibm.com> PR-URL: https://github.com/nodejs/node/pull/33378 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Zeyu Yang <himself65@outlook.com> Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>

view details

Ruben Bridgewater

commit sha da7be6979e3cb097a75f8cf93895deb0f1002002

doc: fix readline key binding documentation The documentation for two key bindings was not correct. Signed-off-by: Ruben Bridgewater <ruben@bridgewater.de> PR-URL: https://github.com/nodejs/node/pull/33361 Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>

view details

Ruben Bridgewater

commit sha 9de08f773ec4efda54ca8c9e3bc4041bade7f46f

lib: update TODO comments This removes one TODO comment and adds another that indicates that readline is currently not able to trigger specific escape sequences. Signed-off-by: Ruben Bridgewater <ruben@bridgewater.de> PR-URL: https://github.com/nodejs/node/pull/33361 Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>

view details

Ruben Bridgewater

commit sha 76c5dc995e7853dc871df118beaea31ced3528aa

repl: support optional chaining during autocompletion This makes sure the autocompletion is able to handle optional chaining notations. Signed-off-by: Ruben Bridgewater <ruben@bridgewater.de> PR-URL: https://github.com/nodejs/node/pull/33450 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>

view details

Ruben Bridgewater

commit sha 19d9e2003ec21b247ccfbb6e0014e1a968ddbd06

repl: simplify repl autocompletion This refactors the repl autocompletion code for simplicity and readability. Signed-off-by: Ruben Bridgewater <ruben@bridgewater.de> PR-URL: https://github.com/nodejs/node/pull/33450 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>

view details

Bradley Farias

commit sha cd4985c488870f95488e6e7a94d280f8d7b1ecd5

esm: doc & validate source values for formats PR-URL: https://github.com/nodejs/node/pull/32202 Reviewed-By: Guy Bedford <guybedford@gmail.com> Reviewed-By: Geoffrey Booth <webmaster@geoffreybooth.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Zeyu Yang <himself65@outlook.com>

view details

Bartosz Sosnowski

commit sha a4e273baf43910ba9e5c66949e56b919f8614fb9

win,fs: use namespaced path in absolute symlinks Use the namespaced (with the \\?\ prefix) paths for symlink targets when the path is absolute. This allows creation of symlinks to files with long filenames. Fixes: https://github.com/nodejs/node/issues/27795 PR-URL: https://github.com/nodejs/node/pull/33351 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

view details

Anna Henningsen

commit sha 6f6bf010a7bfde32f4015758ae2f2af8b45cb612

src: use symbol to store `AsyncWrap` resource Use a symbol on the bindings object to store the public resource object, rather than a `v8::Global` Persistent. This has several advantages: - It’s harder to inadvertently create memory leaks this way. The garbage collector sees the `AsyncWrap` → resource link like a regular JS property, and can collect the objects as a group, even if the resource object should happen to point back to the `AsyncWrap` object. - This will make it easier in the future to use `owner_symbol` for this purpose, which is generally the direction we should be moving the `async_hooks` API into (i.e. using more public objects instead of letting internal wires stick out). PR-URL: https://github.com/nodejs/node/pull/31745 Reviewed-By: Stephen Belanger <admin@stephenbelanger.com> Reviewed-By: David Carlier <devnexen@gmail.com> Reviewed-By: Denys Otrishko <shishugi@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Minwoo Jung <nodecorelab@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com> Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>

view details

Anna Henningsen

commit sha b6b82cba27da9ef83bfef67cac9d3593bd72c0e2

src: use enum for refed flag on native immediates Refs: https://github.com/nodejs/node/pull/33320#discussion_r423141443 PR-URL: https://github.com/nodejs/node/pull/33444 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Zeyu Yang <himself65@outlook.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>

view details

Anna Henningsen

commit sha c45313b3ad47d7e7aa7d204d3ac002a5bbdf3bcb

worker: perform initial port.unref() before preload modules The refcount of the internal communication port is relevant for stdio, but the `port.unref()` call effectively resets any `.ref()` calls happening during stdio operations happening before it. Therefore, do the `.unref()` call before loading preload modules, which may cause stdio operations. Fixes: https://github.com/nodejs/node/issues/31777 PR-URL: https://github.com/nodejs/node/pull/33455 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>

view details

Juan José Arboleda

commit sha 39ceb6ae785e274422369e3bf6834a896e10c232

src: remove unused headers in src/util.h PR-URL: https://github.com/nodejs/node/pull/33070 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Sam Roberts <vieuxtech@gmail.com>

view details

push time in 4 days

issue commentnodejs/modules

Executing loader hook functions

Hi, I'd like to try to get a consolidated To Do list for loaders. We currently have https://github.com/nodejs/modules/projects/8; is that up to date? If it's missing any must-haves that you think loaders need in order to unflag, can you create issues for those features (if they don't exist already) and add them to the board?

coreyfarrell

comment created time in 4 days

issue closedjashkenas/coffeescript

crash with typeof 10n

kubuntu@kubuntu:~/prog$ node -v
v10.19.0
kubuntu@kubuntu:~/prog$ node
> typeof 10n
'bigint'
> 
kubuntu@kubuntu:~/prog$ coffee -v
CoffeeScript version 1.8.0
kubuntu@kubuntu:~/prog$ coffee 
coffee> typeof 10n
Thrown:
{ [[stdin]:1:10: error: unexpected n
typeof 10n
         ^]
  location:
   { first_line: 0, first_column: 9, last_line: 0, last_column: 9 },
  toString: [Function: syntaxErrorToString],
  code: 'typeof 10n\n',
  filename: undefined }
coffee> readline.js:1086
            throw err;
            ^

TypeError [ERR_INVALID_CALLBACK]: Callback must be a function
  at maybeCallback (fs.js:128:9)
  at Object.write (fs.js:540:14)
  at REPLServer.<anonymous> (/home/kubuntu/prog/node_modules/coffee-script/lib/coffee-script/repl.js:121:12)
  at REPLServer.emit (events.js:203:15)
  at REPLServer.EventEmitter.emit (domain.js:448:20)
  at REPLServer.Interface._onLine (readline.js:308:10)
  at REPLServer.Interface._line (readline.js:656:8)
  at REPLServer.Interface._ttyWrite (readline.js:937:14)
  at REPLServer.self._ttyWrite (repl.js:715:7)
  at ReadStream.onkeypress (readline.js:184:10)
  at ReadStream.emit (events.js:203:15)
  at ReadStream.EventEmitter.emit (domain.js:448:20)
  at emitKeys (internal/readline.js:424:14)
  at emitKeys.next (<anonymous>:null:null)
  at ReadStream.onData (readline.js:1073:36)
  at ReadStream.emit (events.js:198:13)
  at ReadStream.EventEmitter.emit (domain.js:448:20)
  at addChunk (_stream_readable.js:288:12)
  at readableAddChunk (_stream_readable.js:269:11)
  at ReadStream.Readable.push (_stream_readable.js:224:10)
  at TTY.onStreamRead [as onread] (internal/stream_base_commons.js:94:17)

kubuntu@kubuntu:~/prog$ 

closed time in 4 days

MarcoCostantini

issue commentjashkenas/coffeescript

crash with typeof 10n

CoffeeScript version 1.8.0

The current version is 2.5.1, and BigInt is supported.

MarcoCostantini

comment created time in 4 days

pull request commentnodejs/node

module: fix check for package.json at volume root

https://ci.nodejs.org/job/node-test-pull-request/31458/ is green, dunno what's going on with the GitHub Actions.

GeoffreyBooth

comment created time in 5 days

pull request commentnodejs/node

doc: add package.json documentation

I've given this some thought, and I do think we should merge modules.md and esm.md. The package.json info can be on that merged page. I think the merged page would still have big “CommonJS Modules” and “ECMAScript Modules” sections, with lots of subsections moved from the current modules.md and esm.md respectively; but the idea is that all content that is not particular to either module system should be outside of those big system-specific sections. And there's a lot of such content! So much so that it's made me more sure that we should merge the pages.

For example, I assume the Source Maps API applies to both module systems, but currently it only lives in modules.md; and conversely Package Exports applies to both but currently only lives in esm.md. And so on. Below I've written a draft outline of the merged page, and you can see how many sections are common, outside of the scope of either module system. For each section I've noted which former file the section came from, or if it is new.

Modules

  • Introduction (new, explain that Node.js has two module systems)

    • CommonJS Modules (based on modules.md introduction)
    • ECMAScript Modules (based on esm.md introduction)
  • Using (based on esm.md section “Enabling”)

    • package.json "type" field
    • Package Scope and File Extensions
    • --input-type flag
  • CommonJS Modules (new; all subsections from modules.md)

    • The Module Wrapper
    • The Module Scope
      • __dirname
      • __filename
      • exports
      • module
      • require(id)
        • require.cache
        • require.extensions
        • require.main
        • require.resolve(request[, options])
          • require.resolve.paths(request)
    • The module Object
      • module.children
      • module.exports
        • exports shortcut
      • module.filename
      • module.id
      • module.loaded
      • module.parent
      • module.paths
      • module.require(id)
    • Accessing The Main Module
    • Core Modules
    • File Modules
      • require of Files with the .mjs Extension (from modules.md “Addenda: The .mjs extension”)
    • Folders as Modules
    • Loading from the Global Folders
    • Loading from node_modules Folders
    • Cycles
    • Caching
      • Module Caching Caveats
  • ECMAScript Modules (new; all subsections from esm.md)

    • import Specifiers
      • Terminology
        • data: Imports
    • import.meta
    • Differences Between ES Modules and CommonJS
      • Mandatory File Extensions
      • No NODE_PATH
      • No require, exports, module.exports, __filename, __dirname
      • No require.resolve
      • No require.extensions
      • No require.cache
      • URL-based Paths
    • Interoperability with CommonJS
      • require
      • import statements
      • import() expressions
    • CommonJS, JSON, and Native Modules
    • Builtin Modules
    • Experimental JSON Modules
    • Experimental Wasm Modules
    • Experimental Top-Level await
    • Experimental Loaders
      • Hooks
        • <code>resolve</code> Hook
        • <code>getFormat</code> Hook
        • <code>getSource</code> Hook
        • <code>transformSource</code> Hook
        • <code>getGlobalPreloadCode</code> Hook
        • <code>dynamicInstantiate</code> Hook
      • Examples
        • HTTPS Loader
        • Transpiler Loader
  • Packages (from esm.md)

    • The package.json File (new section introducing the file itself, with very brief subsections that are nothing more than links to the appropriate sections)
      • "exports"
      • "main"
      • "name"
      • "type"
    • Package Entry Points
      • Main Entry Point Export
      • Subpath Exports
      • Package Exports Fallbacks
      • Exports Sugar
      • Conditional Exports
      • Nested conditions
      • Self-referencing a package using its name
    • Dual CommonJS/ES Module Packages
      • Dual Package Hazard
      • Writing Dual Packages While Avoiding or Minimizing Hazards
        • Approach #1: Use an ES Module Wrapper
        • Approach #2: Isolate State
  • Utility Methods (from modules.md “The Module Object”)

    • module.builtinModules
    • module.createRequire(filename)
    • module.createRequireFromPath(filename)
    • module.syncBuiltinESMExports())
  • Source Map V3 Support (from modules.md)

    • module.findSourceMap(path[, error])
    • Class: module.SourceMap
      • new SourceMap(payload)
      • sourceMap.payload
      • sourceMap.findEntry(lineNumber, columnNumber)
  • Resolution Algorithms (new)

    • CommonJS Resolution Algorithm (from modules.md section “All Together...”)
    • ECMAScript Modules Resolution Algorithm (from esm.md section “Resolution Algorithm”)
      • Features
      • Resolver Algorithm
      • Customizing ESM specifier resolution algorithm
  • Tips for Package Manager Authors (from modules.md “Package Manager Tips”)

For reference, here are the current full outlines of each page:

<details> <summary>Modules</summary>

  • Accessing the main module
  • Addenda: Package Manager Tips
  • Addenda: The .mjs extension
  • All Together...
  • Caching
    • Module Caching Caveats
  • Core Modules
  • Cycles
  • File Modules
  • Folders as Modules
  • Loading from node_modules Folders
  • Loading from the global folders
  • The module wrapper
  • The module scope
    • __dirname
    • __filename
    • exports
    • module
    • require(id)
      • require.cache
      • require.extensions
      • require.main
      • require.resolve(request[, options])
        • require.resolve.paths(request)
  • The module Object
    • module.children
    • module.exports
      • exports shortcut
    • module.filename
    • module.id
    • module.loaded
    • module.parent
    • module.paths
    • module.require(id)
  • The Module Object
    • module.builtinModules
    • module.createRequire(filename)
    • module.createRequireFromPath(filename)
    • module.syncBuiltinESMExports()
  • Source Map V3 Support
    • module.findSourceMap(path[, error])
    • Class: module.SourceMap
      • new SourceMap(payload)
      • sourceMap.payload
      • sourceMap.findEntry(lineNumber, columnNumber)

</details>

<details> <summary>ECMAScript Modules</summary>

  • Introduction
  • Enabling
    • package.json "type" field
    • Package Scope and File Extensions
    • --input-type flag
  • Packages
    • Package Entry Points
      • Main Entry Point Export
      • Subpath Exports
      • Package Exports Fallbacks
      • Exports Sugar
      • Conditional Exports
      • Nested conditions
      • Self-referencing a package using its name
    • Dual CommonJS/ES Module Packages
      • Dual Package Hazard
      • Writing Dual Packages While Avoiding or Minimizing Hazards
        • Approach #1: Use an ES Module Wrapper
        • Approach #2: Isolate State
  • import Specifiers
    • Terminology
      • data: Imports
  • import.meta
  • Differences Between ES Modules and CommonJS
    • Mandatory file extensions
    • No NODE_PATH
    • No require, exports, module.exports, __filename, __dirname
    • No require.resolve
    • No require.extensions
    • No require.cache
    • URL-based paths
  • Interoperability with CommonJS
    • require
    • import statements
    • import() expressions
  • CommonJS, JSON, and Native Modules
  • Builtin modules
  • Experimental JSON Modules
  • Experimental Wasm Modules
  • Experimental Top-Level await
  • Experimental Loaders
    • Hooks
      • <code>resolve</code> hook
      • <code>getFormat</code> hook
      • <code>getSource</code> hook
      • <code>transformSource</code> hook
      • <code>getGlobalPreloadCode</code> hook
      • <code>dynamicInstantiate</code> hook
    • Examples
      • HTTPS loader
      • Transpiler loader
  • Resolution Algorithm
    • Features
    • Resolver Algorithm
    • Customizing ESM specifier resolution algorithm

</details>

aduh95

comment created time in 5 days

Pull request review commentnodejs/node

esm: fix annotations on resolve hook doc snippet

 condition list **must** be passed through to the `defaultResolve` function. ```js /**  * @param {string} specifier- * @param {object} context- * @param {string} context.parentURL- * @param {string[]} context.conditions- * @param {function} defaultResolve- * @returns {object} response- * @returns {string} response.url+ * @param {{+ *   parentURL:!(string|undefined),+ *   conditions:!(Array<string>),
 *   parentURL: !(string|undefined),
 *   conditions: !(Array<string>),

Does the spec allow a space here? And what does the ! mean?

DerekNonGeneric

comment created time in 5 days

issue commentnodejs/node

Special treatment for package.json resolution and exports?

So I'm not opposed to creating this package.json exception, but I would prefer if we didn't because of the education concerns (makes "exports" harder to learn and therefore slows adoption) and because of the potential for bugs (now there's one more code path in our loader, users might think that package.json being available when they didn't export it is a bug, etc.). And if someday some other tool reads the "exports" exported paths, perhaps to generate an import map, is it supposed to include package.json or not? This exception just makes the whole feature permanently more complicated, for what feels to me like a fairly small temporary gain of allowing a few tools to not need to upgrade.

Which makes me wonder, just how many tools are we talking about? If it's in the dozens or even the low hundreds, then I think a better solution is for those tools to just update to use a different method for getting this package metadata. I read through some of the linked issues to this one and apparently plenty of tools haven't had this issue, like Webpack and Rollup. I think it's premature for Node to jump to a solution when we don't have a good sense of how widespread the problem is. It's not the case that all package authors need to add package.json as an export—it's only that tools looking for a /package.json export need to use other means of finding it, like Webpack and Rollup already do.

ctavan

comment created time in 5 days

pull request commentnodejs/node

esm: unflag import.meta.resolve

I think there is consensus that we can ship an equivalent:

import { resolveURL } from 'module'; // <---- this

import { promises as fs } from 'fs';
const pkgUrl = await resolveURL(import.meta, 'pkg/');
const pjson = await fs.readFile(new URL('package.json', pkgUrl));

And potentially add it to import.meta later on when there's more standardization.

guybedford

comment created time in 5 days

push eventGeoffreyBooth/node

Geoffrey Booth

commit sha cd2dc863c33233e9ec1227c432aa692ea151bfb6

module: fix check for package.json at volume root

view details

push time in 5 days

Pull request review commentnodejs/node

esm: fix annotations on resolve hook doc snippet

 condition list **must** be passed through to the `defaultResolve` function. ```js /**  * @param {string} specifier- * @param {object} context- * @param {string} context.parentURL- * @param {string[]} context.conditions- * @param {function} defaultResolve- * @returns {object} response- * @returns {string} response.url+ * @param {{+ *   parentURL:!(string|undefined),+ *   conditions:Array<string>,+ * }} context+ * @param {Function} defaultResolve+ * @returns {{url:string}}  */-export async function resolve(specifier, context, defaultResolve) {+export function resolve(specifier, context, defaultResolve) {   const { parentURL = null } = context;-  if (someCondition) {+  if (Math.random()) { // Some condition.
  if (Math.random() > 0.5) { // Some condition.
DerekNonGeneric

comment created time in 5 days

Pull request review commentnodejs/node

esm: fix annotations on resolve hook doc snippet

 condition list **must** be passed through to the `defaultResolve` function. ```js /**  * @param {string} specifier- * @param {object} context- * @param {string} context.parentURL- * @param {string[]} context.conditions- * @param {function} defaultResolve- * @returns {object} response- * @returns {string} response.url+ * @param {{+ *   parentURL:!(string|undefined),+ *   conditions:Array<string>,+ * }} context+ * @param {Function} defaultResolve+ * @returns {{url:string}}  */-export async function resolve(specifier, context, defaultResolve) {+export function resolve(specifier, context, defaultResolve) {   const { parentURL = null } = context;-  if (someCondition) {+  if (Math.random()) { // Some condition.

Sure, but this makes the example harder to understand in my opinion. Why do compilers need to be able to compile this at all? Isn't the point of fixing the signature so that users can copy/paste this example and then replace the body with their own?

DerekNonGeneric

comment created time in 5 days

push eventGeoffreyBooth/node

Geoffrey Booth

commit sha 036dfc124cdfbe883c1fb7f4fb077d34bc4a1fe4

module: fix check for package.json at volume root

view details

push time in 5 days

Pull request review commentnodejs/node

esm: fix annotations on getFormat hook doc snippet

 a URL should be interpreted. This can be one of the following: ```js /**  * @param {string} url- * @param {object} context (currently empty)- * @param {function} defaultGetFormat- * @returns {object} response- * @returns {string} response.format+ * @param {Object} context (currently empty)+ * @param {Function} defaultGetFormat+ * @returns {{format:string}} response  */-export async function getFormat(url, context, defaultGetFormat) {-  if (someCondition) {+export function getFormat(url, context, defaultGetFormat) {+  if (Math.random()) { // Some condition.

Same feedback as other PR. I think these two PRs can be merged.

DerekNonGeneric

comment created time in 5 days

Pull request review commentnodejs/node

esm: fix annotations on resolve hook doc snippet

 condition list **must** be passed through to the `defaultResolve` function. ```js /**  * @param {string} specifier- * @param {object} context- * @param {string} context.parentURL- * @param {string[]} context.conditions- * @param {function} defaultResolve- * @returns {object} response- * @returns {string} response.url+ * @param {{+ *   parentURL:!(string|undefined),+ *   conditions:Array<string>,+ * }} context+ * @param {Function} defaultResolve+ * @returns {{url:string}}  */-export async function resolve(specifier, context, defaultResolve) {+export function resolve(specifier, context, defaultResolve) {   const { parentURL = null } = context;-  if (someCondition) {+  if (Math.random()) { // Some condition.     // For some or all specifiers, do some custom logic for resolving.     // Always return an object of the form {url: <string>}     return {-      url: (parentURL) ?-        new URL(specifier, parentURL).href : new URL(specifier).href+      url: parentURL ?+        new URL(specifier, parentURL).href :+        new URL(specifier).href,     };   }-  if (anotherCondition) {-    // When calling the defaultResolve, the arguments can be modified. In this+  if (Math.random()) { // Another condition.+    // When calling `defaultResolve`, the arguments can be modified. In this     // case it's adding another value for matching conditional exports.     return defaultResolve(specifier, {       ...context,-      conditions: [...context.conditions, 'another-condition'],+      conditions: context.conditions.concat(['another-condition']),

Why is this an improvement?

DerekNonGeneric

comment created time in 5 days

Pull request review commentnodejs/node

esm: fix annotations on resolve hook doc snippet

 condition list **must** be passed through to the `defaultResolve` function. ```js /**  * @param {string} specifier- * @param {object} context- * @param {string} context.parentURL- * @param {string[]} context.conditions- * @param {function} defaultResolve- * @returns {object} response- * @returns {string} response.url+ * @param {{+ *   parentURL:!(string|undefined),+ *   conditions:Array<string>,+ * }} context+ * @param {Function} defaultResolve+ * @returns {{url:string}}  */-export async function resolve(specifier, context, defaultResolve) {+export function resolve(specifier, context, defaultResolve) {   const { parentURL = null } = context;-  if (someCondition) {+  if (Math.random()) { // Some condition.

Is this necessary? If we're going to use this it should be Math.random() > 0.5, so that it's not always true; but why is just someCondition a problem?

DerekNonGeneric

comment created time in 5 days

pull request commentnodejs/node

module: fix check for package.json at volume root

Note we also have the esm resolver case to check too? Or is that already working?

That seems to already be working. I did the test described in https://github.com/nodejs/node/issues/33438 and got that to pass. I also tested one level down, where an index.cjs contained import('./test.js') and test.js contained import fs from 'fs', and that worked. Ditto when renaming index.cjs to index.js.

GeoffreyBooth

comment created time in 6 days

PR opened nodejs/node

Reviewers
module: fix check for package.json at volume root ES Modules

Fixes https://github.com/nodejs/node/issues/33438. A package.json at the volume root containing "type": "module" now behaves as documented. Thanks to @vitalets for pinpointing exactly where the problem was.

No idea how to write a test for this, but I tested it manually and this fixes the issue.

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

  • [x] make -j4 test (UNIX), or vcbuild test (Windows) passes
  • [ ] tests and/or benchmarks are included
  • [x] commit message follows commit guidelines

cc @nodejs/modules-active-members

<!-- Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -->

+2 -2

0 comment

1 changed file

pr created time in 6 days

create barnchGeoffreyBooth/node

branch : fix-package-json-type-at-root

created branch time in 6 days

issue commentnodejs/modules

add API for "package dir"

As paths are URLs in ESM, "dir" is perhaps not the best name. But aside from naming, yes, this would be a good method to expose. In https://github.com/nodejs/node/issues/33460#issuecomment-630968792 I had suggested resolvePackageRoot.

ljharb

comment created time in 6 days

pull request commentnodejs/node

module: CJS exports detection

@GeoffreyBooth it would be interesting to also get results that ignore __esModule, and separately, that take __esModule into account to indicate whether it has named exports or not. I suspect those numbers would look much better with either of those variants, and would love to see my intuition checked.

You're welcome to check out the repo and modify it however you wish. Please let me know what you find. I already excluded exports named default as those obviously wouldn't be allowed as names of exports in ESM. I think the PR itself includes special handling of __esModule.

guybedford

comment created time in 6 days

pull request commentnodejs/node

module: CJS exports detection

I wrote some code to test this out: https://github.com/GeoffreyBooth/node-test-commonjs-named-exports. It took a lot more code and effort than expected, so please check my work in case my results are tainted by bugs. There's a README in the repo.

Anyway the bottom line is that of 936 packages tested (from within npm's top 1000):

  • 62% of packages (580 of 936) had all CommonJS named exports detected.

  • 5% of packages (51 of 936) had some but not all CommonJS named exports detected.

  • 33% of packages (305 of 936) had no CommonJS named exports detected.

And of all the named exports of all of those packages, 3,390 of 22,579 CommonJS named exports (15%) were detected successfully.

<details> <summary>Packages with all CommonJS named exports detected:</summary>

  • async
  • minimist
  • ms
  • graceful-readlink
  • through2
  • inherits
  • coffee-script
  • yeoman-generator
  • xtend
  • jquery
  • source-map
  • ansi-regex
  • react
  • extend
  • object-assign
  • wrappy
  • isarray
  • once
  • brace-expansion
  • xml2js
  • redis
  • bindings
  • hoek
  • strip-ansi
  • escape-string-regexp
  • asap
  • esprima
  • path-is-absolute
  • xmlbuilder
  • yosay
  • has-flag
  • jade
  • envify
  • mime-types
  • nopt
  • util-deprecate
  • has-ansi
  • ejs
  • string_decoder
  • inflight
  • body-parser
  • entities
  • number-is-nan
  • concat-map
  • pinkie-promise
  • connect
  • double-ended-queue
  • concat-stream
  • json-stringify-safe
  • classnames
  • mysql
  • redis-commands
  • acorn
  • isstream
  • oauth
  • loader-utils
  • argparse
  • jstransform
  • tough-cookie
  • uuid
  • passport-strategy
  • socket.io-client
  • browserify
  • ramda
  • es6-symbol
  • ember-cli-version-checker
  • babel-core
  • tunnel-agent
  • domelementtype
  • parseurl
  • get-stdin
  • caseless
  • escape-html
  • hawk
  • boom
  • chokidar
  • broccoli-funnel
  • loose-envify
  • oauth-sign
  • utils-merge
  • util
  • passport-oauth2
  • har-validator
  • path-to-regexp
  • aws-sign2
  • stringstream
  • lru-cache
  • lodash.keys
  • cli-color
  • os-tmpdir
  • es6-iterator
  • css
  • options
  • dom-serializer
  • string-width
  • rsvp
  • os-homedir
  • ultron
  • path
  • split
  • js-tokens
  • immutable
  • on-finished
  • sprintf-js
  • xmldom
  • unique-random-array
  • cookie
  • uglify-to-browserify
  • passport-oauth
  • querystring
  • broccoli-babel-transpiler
  • type-detect
  • node-pre-gyp
  • escodegen
  • lodash.rest
  • component-emitter
  • nodemailer
  • temp
  • phantomjs
  • depd
  • ee-first
  • react-dom
  • unique-random
  • cli-table
  • open
  • send
  • ini
  • deep-equal
  • finalhandler
  • jsonify
  • wrench
  • lodash.assign
  • serve-static
  • js-base64
  • crypto
  • socket.io-parser
  • diff
  • estraverse
  • stack-trace
  • xmlhttprequest
  • camelcase
  • type-is
  • decamelize
  • duplexer2
  • invariant
  • sliced
  • node.extend
  • json-stable-stringify
  • duplexer
  • cookie-signature
  • vary
  • tar
  • deep-extend
  • is-finite
  • jshint
  • path-exists
  • replace-ext
  • map-stream
  • is-buffer
  • JSONStream
  • read
  • html-minifier
  • exit
  • accepts
  • walk
  • progress
  • amdefine
  • tmp
  • mute-stream
  • callsite
  • extsprintf
  • repeating
  • findup-sync
  • events
  • swig
  • content-type
  • strip-bom
  • rc
  • source-map-support
  • passport-oauth1
  • is-utf8
  • etag
  • fresh
  • has-binary
  • encoding
  • adm-zip
  • restify
  • deep-eql
  • is-windows
  • foreachasync
  • klaw
  • falafel
  • assertion-error
  • engine.io
  • cookie-parser
  • bytes
  • performance-now
  • thunkify
  • array-uniq
  • typedarray
  • url
  • merge-descriptors
  • convert-source-map
  • is-extendable
  • isobject
  • os-locale
  • text-table
  • uid2
  • sparkles
  • cliui
  • y18n
  • find-up
  • strip-json-comments
  • gulp-rename
  • end-of-stream
  • broccoli-persistent-filter
  • is-relative
  • esprima-fb
  • range-parser
  • defined
  • update-notifier
  • lodash.template
  • raf
  • prr
  • socket.io-adapter
  • broccoli-filter
  • css-parse
  • errno
  • growl
  • is-promise
  • indexof
  • array-flatten
  • function-bind
  • bcrypt
  • image-size
  • ansi
  • markdown
  • requires-port
  • hooker
  • keypress
  • recast
  • lodash.merge
  • brfs
  • content-disposition
  • pretty-bytes
  • gaze
  • lcid
  • component-type
  • stream-combiner
  • node-gyp
  • raw-body
  • kind-of
  • read-pkg-up
  • unc-path-regex
  • extend-shallow
  • nodemailer-shared
  • lodash._reinterpolate
  • machine
  • ndarray
  • cross-spawn
  • babel-polyfill
  • is-unc-path
  • MD5
  • esnextguardian
  • foreach
  • jsprim
  • array-differ
  • watch
  • dtrace-provider
  • lodash.defaults
  • mv
  • negotiator
  • hapi
  • proxy-addr
  • invert-kv
  • punycode
  • node-static
  • copy-dereference
  • is-my-json-valid
  • pify
  • media-typer
  • code-point-at
  • is-fullwidth-code-point
  • node-hid
  • globby
  • xml2json
  • nodemailer-fetch
  • soap
  • wangzhi
  • esutils
  • broccoli-merge-trees
  • arrify
  • pause
  • googleapis
  • multipipe
  • cron
  • lodash._mapcache
  • word-wrap
  • uniq
  • iconv
  • basic-auth
  • del
  • urllib
  • error
  • nedb
  • fancy-log
  • mqtt
  • amqplib
  • express-session
  • is-glob
  • cssom
  • defaults
  • retry
  • on-headers
  • grunt-contrib-jshint
  • symlink-or-copy
  • nano
  • domhandler
  • next-tick
  • setimmediate
  • cryptiles
  • md5
  • htmlparser
  • string-template
  • knox
  • is-extglob
  • lodash.get
  • dargs
  • unpipe
  • koa
  • map-obj
  • emitter-component
  • lower-case
  • urix
  • cookiejar
  • lodash._reescape
  • lodash._reevaluate
  • lodash.isplainobject
  • beeper
  • has-gulplog
  • lodash._stack
  • sockjs
  • blank-object
  • detective
  • base64-js
  • irc
  • grunt-contrib-uglify
  • lazy-cache
  • safe-json-stringify
  • serve-favicon
  • date-now
  • to-array
  • character-parser
  • findit
  • domify
  • babelify
  • batch
  • xml
  • noflo
  • clone-stats
  • constantinople
  • gulp-uglify
  • vinyl-sourcemaps-apply
  • multimatch
  • twit
  • flux
  • dotenv
  • pad-component
  • shell-quote
  • revalidator
  • lodash._arraymap
  • sntp
  • util-extend
  • with
  • jws
  • merge-defaults
  • isomorphic-fetch
  • private
  • glogg
  • parse5
  • topo
  • grunt-contrib-clean
  • sentence-case
  • dnode
  • reduce-component
  • rework
  • memoizee
  • taketalk
  • query-string
  • natural
  • charm
  • byline
  • buffers
  • shortid
  • cors
  • liftoff
  • follow
  • cross-spawn-async
  • strip-indent
  • isemail
  • lodash._baseisequal
  • validate.io-number
  • redux
  • sync-exec
  • abstract-leveldown
  • browserify-transform-tools
  • hypher
  • compression
  • config-chain
  • broccoli-plugin
  • xdg-basedir
  • regexp-clone
  • win-spawn
  • lodash._arrayeach
  • dezalgo
  • read-chunk
  • koa-compose
  • from
  • archy
  • type-component
  • babel-traverse
  • sylvester
  • gulp-concat
  • lodash.assigninwith
  • bit-twiddle
  • strict-uri-encode
  • mongojs
  • matcher-collection
  • ansi-wrap
  • readline-sync
  • http
  • jsonschema
  • better-assert
  • acorn-globals
  • pump
  • gruntfile-editor
  • iniparser
  • signal-exit
  • insert-css
  • json-schema
  • mem-fs-editor
  • github-username
  • any-promise
  • block-stream
  • azure-common
  • has
  • weak-map
  • object.assign
  • for-in
  • event-emitter
  • yeoman-test
  • backoff
  • iota-array
  • spawn-sync
  • each-async
  • imagemagick
  • stream-consume
  • pend
  • detect-conflict
  • validate.io-object
  • warning
  • is-plain-object
  • babylon
  • babel-template
  • typical
  • upper-case
  • lodash.foreach
  • grunt-contrib-watch
  • load-grunt-tasks
  • baconjs
  • nth-check
  • prettyjson
  • dom-walk
  • lodash.keysin
  • observ
  • pretty-hrtime
  • fast-ordered-set
  • precond
  • level-packager
  • promised-io
  • is-plain-obj
  • css-what
  • gulp-template
  • maxmin
  • ast-types
  • array-series
  • three
  • run-sequence
  • broccoli-kitchen-sink-helpers
  • slash
  • passport-local
  • typechecker
  • read-pkg
  • anymatch
  • tunnel
  • regenerator
  • watchify
  • array-parallel
  • @linclark/pkg
  • nodemailer-smtp-transport
  • browser-sync
  • for-own
  • kareem
  • gulp-install
  • gl-matrix
  • static-module
  • url-join
  • tedious
  • binary
  • require-all
  • bufferjs
  • camelcase-keys
  • json3
  • busboy
  • markdown-it
  • loud-rejection
  • redent
  • require-directory
  • trim-newlines
  • onetime
  • pngjs
  • lodash.clonedeep
  • typedarray-to-buffer
  • grunt-contrib-copy
  • component-props
  • html-entities
  • lodash.isstring
  • temporary
  • useragent
  • async-each
  • split2
  • reflect-metadata
  • gulp-conflict
  • to-function
  • lodash.debounce
  • to-no-case
  • cwise-compiler
  • throttleit
  • typedarray-pool
  • lodash.isfunction
  • fd-slicer
  • lodash._basefor
  • collections
  • validate.io-integer
  • forwarded
  • tar-stream
  • is-object
  • ftp
  • lodash._baseslice
  • lodash._baseeach
  • ansi-color
  • fj-curry
  • agentkeepalive
  • ltx
  • coveralls
  • to-space-case
  • opn
  • as-array
  • hook.io
  • lodash.isobject
  • repeat-string
  • buffer-equal
  • lodash._baseflatten
  • tildify
  • is-url
  • grunt-contrib-concat
  • node-promise
  • js-string-escape
  • feedparser
  • quick-temp
  • sync-request
  • trim
  • promise-map-series
  • lodash.clone
  • hoist-non-react-statics
  • recursive-readdir
  • component-bind
  • ap
  • request-progress
  • level-sublevel

</details>

<details> <summary>Packages with some but not all CommonJS named exports detected:</summary>

  • debug
  • readable-stream
  • commander
  • express
  • optimist
  • cheerio
  • uglify-js
  • superagent
  • shelljs
  • mocha
  • core-util-is
  • htmlparser2
  • bl
  • chai
  • tape
  • d3
  • bunyan
  • process
  • requirejs
  • passport
  • fs
  • morgan
  • gm
  • commoner
  • ua-parser-js
  • nodeunit
  • http-errors
  • needle
  • webpack
  • pull-stream
  • autoprefixer
  • sequelize
  • node-fetch
  • follow-redirects
  • babel-types
  • consolidate
  • figures
  • transformers
  • node-notifier
  • assert
  • libmime
  • objnest
  • bn.js
  • xlsx
  • engine.io-client
  • mongoskin
  • jison
  • mssql
  • iced-runtime
  • mathjs
  • LiveScript

</details>

<details> <summary>Packages with no CommonJS named exports detected:</summary>

  • lodash
  • request
  • underscore
  • chalk
  • glob
  • colors
  • bluebird
  • q
  • mkdirp
  • through
  • moment
  • gulp-util
  • ember-cli-babel
  • semver
  • minimatch
  • node-uuid
  • core-js
  • rimraf
  • yargs
  • mime
  • qs
  • sax
  • promise
  • supports-color
  • mongodb
  • wordwrap
  • clone
  • es6-promise
  • fs-extra
  • handlebars
  • socket.io
  • winston
  • ansi-styles
  • iconv-lite
  • js-yaml
  • mongoose
  • ws
  • postcss
  • grunt
  • es5-ext
  • resolve
  • underscore.string
  • mime-db
  • abbrev
  • graceful-fs
  • when
  • process-nextick-args
  • marked
  • balanced-match
  • form-data
  • pkginfo
  • aws-sdk
  • combined-stream
  • gulp
  • event-stream
  • pinkie
  • inquirer
  • delayed-stream
  • co
  • less
  • dateformat
  • is-typedarray
  • methods
  • backbone
  • ember-cli-htmlbars
  • validator
  • forever-agent
  • json5
  • http-signature
  • bson
  • d
  • merge
  • which
  • traverse
  • joi
  • clean-css
  • npm
  • is-absolute
  • mustache
  • should
  • eventemitter2
  • bignumber.js
  • vinyl
  • mongodb-core
  • eventemitter3
  • jsonfile
  • formidable
  • log4js
  • css-select
  • argx
  • assert-plus
  • http-proxy
  • big.js
  • ncp
  • bower
  • is
  • request-promise
  • iftype
  • nomnom
  • cli
  • rx
  • should-type
  • eyes
  • string
  • restler
  • nconf
  • native-or-bluebird
  • highlight.js
  • mout
  • tap
  • js-beautify
  • faye-websocket
  • moment-timezone
  • got
  • ee-class
  • sprintf
  • websocket-driver
  • hogan.js
  • typescript
  • domutils
  • lodash-node
  • websocket
  • pako
  • ip
  • globule
  • pseudomap
  • npmlog
  • yallist
  • inflection
  • user-home
  • prelude-ls
  • jsonwebtoken
  • levelup
  • window-size
  • sinon
  • generic-pool
  • verror
  • ssh2
  • vinyl-fs
  • websocket-extensions
  • csv
  • global
  • eslint
  • react-tools
  • hyperquest
  • hubot
  • vows
  • cycle
  • validate.io-array
  • archiver
  • amqp
  • step
  • statuses
  • pegjs
  • object-keys
  • xregexp
  • ipaddr.js
  • jsonparse
  • boolbase
  • optionator
  • sshpk
  • argv
  • vow
  • nunjucks
  • long
  • jszip
  • utile
  • elasticsearch
  • color
  • babel-preset-es2015
  • virtual-dom
  • change-case
  • yamljs
  • hashish
  • pluralize
  • deepmerge
  • traceur
  • charenc
  • crypt
  • crypto-js
  • es6-shim
  • osenv
  • run-async
  • leveldown
  • log
  • gulplog
  • level
  • kew
  • dot
  • void-elements
  • typpy
  • highland
  • check-types
  • bops
  • hat
  • benchmark
  • xhr
  • base62
  • normalize-package-data
  • readdirp
  • buffer-crc32
  • should-format
  • should-equal
  • keygrip
  • arrayreduce
  • sugar
  • wiredep
  • axios
  • jasmine-node
  • istextorbinary
  • duplexify
  • jstransformer
  • yeoman-environment
  • csv-parse
  • jsbn
  • pause-stream
  • color-convert
  • walk-sync
  • html-wiring
  • log-symbols
  • class-extend
  • through3
  • microtime
  • source-map-resolve
  • ee-log
  • he
  • yaml
  • xmlrpc
  • docopt
  • shimmer
  • big-integer
  • lazy
  • cookies
  • tv4
  • lie
  • dustjs-linkedin
  • phantom
  • ee-types
  • base64url
  • required-keys
  • yeoman-assert
  • mpromise
  • object-path
  • package
  • yeoman-welcome
  • resource
  • samsam
  • asn1
  • colors.css
  • mpath
  • protobufjs
  • mz
  • fis
  • rx-lite
  • crc
  • deferred
  • lodash.isarray
  • knex
  • memcached
  • queue-async
  • lodash-compat
  • ssh2-streams
  • jwt-simple
  • cradle
  • flat
  • blessed
  • signals
  • min-document
  • debounce
  • mquery
  • strftime
  • muri
  • slug
  • plist
  • ul
  • walkdir
  • color-string
  • color-name
  • expect.js
  • node-int64
  • interpret
  • micromatch
  • define-properties
  • hooks-fixed
  • protoclass
  • gulp-sourcemaps
  • vue
  • exec-sh
  • unist-util-visit
  • wd
  • node-forge
  • coffeeify
  • url-parse
  • cylon
  • sift
  • extended
  • harmony-reflect
  • pouchdb
  • knockout
  • eco
  • gh-got
  • platform
  • cuid
  • koa-router
  • node-fs

</details>

There aren't 1000 packages tested because the rest had various issues like being Windows-only, or failing to build on my machine, etc. But I think this sample should be representative.

guybedford

comment created time in 6 days

issue commentnodejs/node

doc: Explicitly state that package.json is no longer exported when using exports

Re the tools needing to update, two things:

  • There aren't that many tools that would need to update. This isn't a case where we have millions of users needing to update their code. The various tools that do this now would need to change, but that's it. A few dozens or hundreds of projects, for a trivial change, and that's it. I understand it's annoying for those tool authors, but there are many tens or hundreds of thousands of package authors who don't need this exception and shouldn't need to spend mental effort learning it.

  • Creating an exception for package.json would enshrine what some on this thread consider a bad pattern, that of stuffing random configuration data into package.json rather than in separate files like .babelrc or wherever. We should perhaps make a new API that returns the path to the package root, e.g. ./node_modules/pkg/, rather than the path to the package.json or the package.json contents, as then tools could use this package root path to potentially read files other than package.json to find their metadata or configuration data.

ctavan

comment created time in 6 days

push eventGeoffreyBooth/node-test-commonjs-named-exports

Geoffrey Booth

commit sha b0ffa7c8034e44367df43f2926997518270b321f

Distinguish between some/no exports detected

view details

push time in 6 days

issue commentnodejs/node

doc: Explicitly state that package.json is no longer exported when using exports

I sympathize with the use case, but I also don't want to take away package authors' ability to define their public API as not including package.json if they wish; and the mental overhead of anyone using "exports" to have to read about/know about this exception is bad UX. And since JSON files aren't import-able, the current pattern doesn't translate well into ESM.

That said, I think there should be a way to get this information easily enough, so if that means a new API, then so be it. import { getPackageMetadata } from 'module' where getPackageMetadata('pkg') returns the root package.json for pkg? Sure, and it could work identically in CommonJS as in ESM. How is this any different or better than just making an exception to "exports"? In my mind, this is equivalent to fs.readFile, in that "exports" already explicitly allows any-file access when people aren't using require or import, so this is the same thing. Or if we can use resolve somehow to achieve the same goal, that would be fine too. We could even create a new API, like import { resolvePackageRoot } from 'module', that would only look at the bare specifier (resolvePackageRoot('pkg')) and throw on any strings that contained slashes; therefore it could also function identically between CommonJS and ESM.

ctavan

comment created time in 6 days

MemberEvent

push eventGeoffreyBooth/node-test-commonjs-named-exports

Geoffrey Booth

commit sha ea4f7f2d6e348bf7ed057f855205a81bbcfe8d92

Add test

view details

push time in 7 days

create barnchGeoffreyBooth/node-test-commonjs-named-exports

branch : master

created branch time in 7 days

created repositoryGeoffreyBooth/node-test-commonjs-named-exports

Test Node.js detection of CommonJS named exports

created time in 7 days

pull request commentnodejs/node

doc: add package.json documentation

Rereading all of this again, I'm struck by how much content really should be shared between docs pages. For example anyone reading the ECMAScript Modules page of the docs really should get a section on Conditional Exports, as most ESM package authors will want to know about that, but this PR moves that content into the package.json page of the docs—which makes sense in its own way, since that content isn't specific to ECMAScript Modules but rather applies to both CommonJS and ECMAScript Modules.

This is making me think that maybe the best organizational structure isn't three separate pages—(CommonJS) Modules, ECMAScript Modules and package.json—but rather just one page, Modules, that includes all this content. What does everyone else think?

aduh95

comment created time in 9 days

Pull request review commentnodejs/node

doc: add package.json documentation

+# `package.json`++<!--introduced_in=REPLACEME-->+<!-- type=misc -->++## Introduction++A `package.json` file defines a package scope. Its parent directory, and all+subfolders below that folder down until the next folder containing another+`package.json`, is considered a _package scope_.++This document aims to describe the fields used by the Node.js+runtime. Other tools (such as+[npm](https://docs.npmjs.com/creating-a-package-json-file)) may use additional+fields which are ignored by Node.js and not documented in this document.++## Supported fields++### `"name"`+<!-- YAML+added:+  - v13.1.0+  - v12.16.0+changes:+  - version: v13.6.0+    pr-url: https://github.com/nodejs/node/pull/31002+    description: Remove the --experimental-resolve-self option.+-->++```json+{+    "name": "package-name"+}+```++The `"name"` field defines your package’s name. Node.js doesn't apply any+restriction on the name field, although the field is ignored if it is not a+string or an empty string.++The `"name"` field can be used in addition to the [`"exports"`][] field to+[self-reference a package using its name][].++### `"exports"`+<!-- YAML+added: v12.7.0+changes:+  - version: v13.2.0+    pr-url: https://github.com/nodejs/node/pull/29978+    description: Implements conditional exports.+  - version: v13.7.0+    pr-url: https://github.com/nodejs/node/pull/31001+    description: Remove the --experimental-conditional-exports option.+  - version: v13.7.0+    pr-url: https://github.com/nodejs/node/pull/31008+    description: Implement logical conditional exports ordering.+-->++```json+{+    "exports": "./index.js"
  "exports": "./index.js"
aduh95

comment created time in 9 days

Pull request review commentnodejs/node

doc: add package.json documentation

+# `package.json`++<!--introduced_in=REPLACEME-->+<!-- type=misc -->++## Introduction++A `package.json` file defines a package scope. Its parent directory, and all+subfolders below that folder down until the next folder containing another+`package.json`, is considered a _package scope_.++This document aims to describe the fields used by the Node.js+runtime. Other tools (such as+[npm](https://docs.npmjs.com/creating-a-package-json-file)) may use additional+fields which are ignored by Node.js and not documented in this document.
fields which are ignored by Node.js and not documented here.
aduh95

comment created time in 9 days

Pull request review commentnodejs/node

doc: add package.json documentation

+# `package.json`++<!--introduced_in=REPLACEME-->+<!-- type=misc -->++## Introduction++A `package.json` file defines a package scope. Its parent directory, and all+subfolders below that folder down until the next folder containing another+`package.json`, is considered a _package scope_.++This document aims to describe the fields used by the Node.js+runtime. Other tools (such as+[npm](https://docs.npmjs.com/creating-a-package-json-file)) may use additional+fields which are ignored by Node.js and not documented in this document.++## Supported fields++### `"name"`+<!-- YAML+added:+  - v13.1.0+  - v12.16.0

This could be confusing since "name" is a very old field, since the 0.x days of Node; I think it's only that Node (as opposed to npm) started using it fairly recently.

aduh95

comment created time in 9 days

Pull request review commentnodejs/node

doc: add package.json documentation

+# `package.json`++<!--introduced_in=REPLACEME-->+<!-- type=misc -->++## Introduction++A `package.json` file defines a package scope. Its parent directory, and all+subfolders below that folder down until the next folder containing another+`package.json`, is considered a _package scope_.++This document aims to describe the fields used by the Node.js+runtime. Other tools (such as+[npm](https://docs.npmjs.com/creating-a-package-json-file)) may use additional+fields which are ignored by Node.js and not documented in this document.++## Supported fields++### `"name"`+<!-- YAML+added:+  - v13.1.0+  - v12.16.0+changes:+  - version: v13.6.0+    pr-url: https://github.com/nodejs/node/pull/31002+    description: Remove the --experimental-resolve-self option.+-->++```json+{+    "name": "package-name"
  "name": "package-name"

I think our docs style is two spaces of indentation.

aduh95

comment created time in 9 days

Pull request review commentnodejs/node

doc: add package.json documentation

 or when referenced by `import` statements within ES module code:  * Files ending in `.cjs`. -* Files ending in `.js` when the nearest parent `package.json` file contains a-  top-level field `"type"` with a value of `"commonjs"`.+* Files ending in `.js` when the nearest parent [`package.json`][] file contains+  a top-level field [`"type"`][] with a value of `"commonjs"`.  * Strings passed in as an argument to `--eval` or `--print`, or piped to `node`   via `STDIN`, with the flag `--input-type=commonjs`. -### `package.json` `"type"` field--Files ending with `.js` will be loaded as ES modules when the nearest parent-`package.json` file contains a top-level field `"type"` with a value of-`"module"`.--The nearest parent `package.json` is defined as the first `package.json` found-when searching in the current folder, that folder’s parent, and so on up-until the root of the volume is reached.--<!-- eslint-skip -->-```js-// package.json-{-  "type": "module"-}-```--```sh-# In same folder as above package.json-node my-app.js # Runs as ES module-```--If the nearest parent `package.json` lacks a `"type"` field, or contains-`"type": "commonjs"`, `.js` files are treated as CommonJS. If the volume root is-reached and no `package.json` is found, Node.js defers to the default, a-`package.json` with no `"type"` field.--`import` statements of `.js` files are treated as ES modules if the nearest-parent `package.json` contains `"type": "module"`.--```js-// my-app.js, part of the same example as above-import './startup.js'; // Loaded as ES module because of package.json-```--Package authors should include the `"type"` field, even in packages where all-sources are CommonJS. Being explicit about the `type` of the package will-future-proof the package in case the default type of Node.js ever changes, and-it will also make things easier for build tools and loaders to determine how the-files in the package should be interpreted.--Regardless of the value of the `"type"` field, `.mjs` files are always treated-as ES modules and `.cjs` files are always treated as CommonJS.- ### Package Scope and File Extensions -A folder containing a `package.json` file, and all subfolders below that folder-down until the next folder containing another `package.json`, is considered a-_package scope_. The `"type"` field defines how `.js` files should be treated-within a particular `package.json` file’s package scope. Every package in a-project’s `node_modules` folder contains its own `package.json` file, so each-project’s dependencies have their own package scopes. A `package.json` lacking a-`"type"` field is treated as if it contained `"type": "commonjs"`.+Every package in a project’s `node_modules` folder usually contains its own+[`package.json`][] file, so each project’s dependencies have their own [package+scopes][]. A [`package.json`][] lacking a [`"type"`][] field is treated as if it
A folder containing a [`package.json`][] file, and all subfolders below that folder
down until the next folder containing another [`package.json`][], is considered a
_package scope_. The [`"type"`][] field defines how `.js` files should be treated
within a particular [`package.json`][] file’s package scope. Every package in a 
project’s `node_modules` folder usually contains its own [`package.json`][] file,
so each project’s dependencies have their own [package scopes][]. A
[`package.json`][] lacking a [`"type"`][] field is treated as if it

It's a little weird to jump straight to discussing node_modules subfolders without first introducing the concept of package scope. The only difference between this version and the old version is that the first two sentences have been removed, but those are pretty vital sentences that define what a package scope is.

Also do we want to linkify every mention of package.json and "type" etc.?

aduh95

comment created time in 9 days

Pull request review commentnodejs/node

doc: add package.json documentation

 path `import feature from 'my-mod/feature/index.js`. #### Main Entry Point Export

It's a bit weird to talk about main entry points in esm.md but not deep entry points, e.g. we cover import 'pkg' but not import 'pkg/feature'. At the very least we need a heading or paragraph that links to the Subpath Exports section.

aduh95

comment created time in 9 days

issue commentjashkenas/coffeescript

Redesign coffeescript.org?

Flattery:

image

Introducing Docup 1.0, the single-page documentation generator for your open source projects (no build step, just a 30KB JavaScript file)

🧙‍♀️ https://docup.now.sh

– @egoist via https://twitter.com/_egoistlily/status/1261673949097627648?s=20

GeoffreyBooth

comment created time in 9 days

CommitCommentEvent

pull request commentdisney/meteor-base

Fix typo in comment

Thanks!

MarceloPrado

comment created time in 10 days

push eventdisney/meteor-base

Marcelo T Prado

commit sha aff3a1d18cc0ddeff66b3c390166911abeebe8d7

Fix typo in comment

view details

Geoffrey Booth

commit sha 9c83d30d670538abd77e7d6af3ff1e21f992865d

Merge pull request #47 from MarceloPrado/patch-1 Fix typo in comment

view details

push time in 10 days

PR merged disney/meteor-base

Fix typo in comment
+1 -1

0 comment

1 changed file

MarceloPrado

pr closed time in 10 days

issue commentjashkenas/coffeescript

Support CoffeeScript on the new `deno` JavaScript engine

Hi @kitsonk, congratulations on shipping Deno 1.0! Any update on support for external compilers?

shreeve

comment created time in 11 days

pull request commentnodejs/node

src: add support for top level await

@GeoffreyBooth in theory we could treat --print as a REPL goal and then support TLA the way we do in the repl itself. I think it would be reasonable to explicitly not support static import with --print unless we find a way to support it in the repl goal. Seem reasonable?

I don't have a preference as to the specific implementation, I want it to 'just work' as I would expect it to as a user; which I understand is hard to define, but that gives us a little wiggle room. What I have in mind is basically, however CommonJS --print works (last expression? returned value?), ESM --print should do the same. I think users would be surprised if import() expressions worked but import statements didn't.

devsnek

comment created time in 14 days

issue commentmicrosoft/TypeScript

Design Meeting Notes, 11/22/2019

You can add a .js to the end of your import paths and it will work!

For Node, but for IDEs? Is Code going to start seeing import './file.js' and look for file.ts there? And linters etc.? Even if the whole ecosystem adapts to this, it's bad UX to ask users to write paths to files that don't exist. That includes import './file' for non-CommonJS contexts.

I understand that changing the model of transpileModule, even if only when this option is enabled, is a painful change to make with ecosystem repercussions. But that seems like pain for the TypeScript development team and possibly authors of integrations like Babel's TypeScript plugin, but little if any pain for end users.

DanielRosenwasser

comment created time in 14 days

issue commentmicrosoft/TypeScript

Design Meeting Notes, 11/22/2019

A lot of our emit happens through ts.transpileModule which works on one file at a time

Forgive my ignorance, but how do you determine what files to transpile? I assume there's some configuration to define something like “include ./src/**/*.ts,” right?

So basically, step 1 is to identify all the files that match that glob; and then step 2 is to transpile each of them. Since in step 1 you have the full list of all files that will be transpiled, in step 2 you can pass that list into transpileModule so it knows what files are on the list for every specifier it encounters, so it can rewrite those extensions and those extensions only. The option which enables this should be explicit that it's only rewriting extensions for files that TypeScript is transpiling, to ignore cases of import statements of non-local files or external libraries.

I understand the reluctance to fix something that isn't broken, in TypeScript maintainers' view, but browsers and Deno will never support CommonJS-style implicit extensions and it's not likely that Node will either (for ESM). If that's what TypeScript continues to insist upon, it will increasingly feel like a bug to users. Maybe that's not a “pot of gold,” but I think good UX is worth striving for.

DanielRosenwasser

comment created time in 14 days

pull request commentnodejs/node

src: add support for top level await

Would you mind elaborating why users might want this?

Again, I wouldn't hold up the PR over this. I just think that we should see if there's a reasonable way to support --print for ESM, as --print isn't so obscure that it isn't used and it would feel like a UX bug for --print to work only sometimes (in CommonJS) and not for all input code.

The testing case I had in mind were Node's own tests, full of code with calls like exec(process.execPath to run Node itself as a child process with various flags. I guess most proper test runners don't typically spawn a new process for each test, so maybe that's not a good example. Another example that comes to mind is shell scripts. A cursory search of GitHub finds plenty of uses in shell for things like protobufjs_dir=$(dirname "$(node --print 'require.resolve("protobufjs")')"):

  • https://github.com/sum0999/RNRepoAnalyzer/blob/0a957bb4c2b690def77bfaca5d715ed53460d2bb/appcenter-sampleapp-react-native-master/appcenter-post-build.sh
  • https://github.com/sylvaindethier/react-custom-props/blob/5ba3136be6c352ba50a8a60e6ecba6bccc5018c6/scripts/release.sh#L16
  • https://github.com/let-z-go/pbrpc.js/blob/4e1527bb243585bbfcfe4acfbb907d512faac37c/bin/pbrpcjs#L50
  • https://github.com/LOKE/nodejs-buildkite-plugin/blob/9bcad953b87a3db5f3dc9c03958e9b4d7042f42f/bin/package#L5

Obviously none of these examples are ESM, but it makes ESM feel second-class whenever the user can only achieve a certain thing via CommonJS or the ESM workaround is more verbose, such as adding console.log somewhere.

devsnek

comment created time in 14 days

issue commentGeoffreyBooth/node-loaders

Discussion: How to sum N loaders?

Let's please discuss on https://github.com/nodejs/modules, I don't want people to need to start following this repo for discussion. I think the issues and PRs on this repo should be particular to the code in this repo.

aurium

comment created time in 14 days

issue closedGeoffreyBooth/node-loaders

Discussion: How to sum N loaders?

I believe pgp-loader alone scarcely will be an use case. Cryptography makes sense if the data must be stored or traffic by insecure places. In a real case it could work together with https-loader or (pending)imap-loader. Like that, many use cases may need to sum loaders to achieve the desired feature.

I think "--experimental-loader" don't support an array of loaders, so what is the best path? Implement the support on Node.js or make a loader of loaders? (I believe it must be a Node.js feature)

Regardless of the chosen path, simply create a line of hooks (where the "defaultHook" parameter is the next loader hook) is enough? I think yes. We must to consider something?

closed time in 14 days

aurium

issue commentmicrosoft/TypeScript

Design Meeting Notes, 11/22/2019

"it does what it does based on cjs"

But this is the problem. CommonJS-style resolution is a Node-specific thing. TypeScript isn't and shouldn't be defined by Node.

If it were me, I would create a new configuration option called “rewrite extensions of static imports of transpiled files” that does just that: when the transpiler encounters a static specifier of a file that the transpiler itself will be transpiling later (or has already transpiled), that specifier is rewritten. It's that straightforward, and it's not a minefield. Make it an experimental option if you want, and see what edge cases it can't cover. If too many people find too many cases where it doesn't rewrite as they'd expect, drop it. But I'm not persuaded that it's unachievable, or that the definition of when something will be rewritten is so difficult to fathom that users can't grasp it.

DanielRosenwasser

comment created time in 15 days

issue commentmicrosoft/TypeScript

Design Meeting Notes, 11/22/2019

I think for dynamic import() specifiers, the author has opted into needing to know what the hell they're doing, and will need to have figured out what the specifiers will be at runtime and will generate the specifier accordingly. This is also an edge case. I think TypeScript can certainly say that they only rewrite extensions and only for static specifiers. @weswigham?

The way to be sure that there isn't some CommonJS trickery going on like file.js.ts is to check the disk when rewriting: if './file.ts' exists, and the configuration says that file.ts will be output as file.js, then rewrite the './file.ts' specifier to './file.js'. Don't rewrite any extensions otherwise.

DanielRosenwasser

comment created time in 15 days

issue commentjashkenas/coffeescript

Proposal: Optional (pre-last) function arguments

So I think you would need to compile into == null rather than === undefined to match the output of ? in other contexts (i.e. null or undefined, not just undefined). There's the complication that since CoffeeScript 2 default parameters are only applied for undefined, to match ES6, so arguably ? in the function parameter context should follow this undefined-only rule.

This also looks challenging to implement. Keep in mind it would need to apply also for => functions and class/object methods. Are you up for taking this on?

celalo

comment created time in 15 days

issue commentjashkenas/coffeescript

Discussion: Barista, the Pluggable CoffeeScript

How hard will be to accomplish this decoupling?

The naïve approach would be to just port parser.js into CoffeeScript, and replace grammar.coffee with that; then update Cakefile to include grammar.coffee compilation like all the other files and get rid of the separate “compile parser” exception. Especially if you used a tool like js2coffee or https://github.com/helixbass/es2coffee, you could do this in an evening.

However the resulting grammar.coffee would be practically unreadable; a switch statement with over a hundred cases. A much better version would be a grammar.coffee that looks at least remotely like what we have today, where the grammar rules are defined in logically-related blocks. Perhaps this can be achieved by defining the blocks first and then using a recursive function with a long nested if statement to drill through them, where the if is ordered like the switch from most complex to least. Alternatively you could do what jison does but on startup at runtime, where the rules are parsed and organized into a data structure similar to that switch statement but in memory. The challenge here would be doing so in a performant way. I'm sure there are probably other approaches; looking at Babel might be useful here.

So the short version is that to do it right, it would be a significant challenge. It doesn't require too much CoffeeScript codebase knowledge, so if you're an experienced developer and want a big task to bite off, it's self-contained albeit challenging.

Alternatively, you could implement a plugin architecture that just avoids the grammar, at least at first. Then you could tackle the grammar refactor as a second stage, or try to find more workarounds like we've already been doing for passing data through the parser. One workaround could be adding more places where PASSTHROUGH_LITERAL is allowed and then having your plugin define new tokens that are passed through as literal JavaScript and then picked up again by the node classes and output as something other than their literal text.

aurium

comment created time in 15 days

issue commentmicrosoft/TypeScript

Design Meeting Notes, 11/22/2019

@weswigham What about specifically just rewriting extensions, especially if this is a feature that is off by default but can be opted into via configuration? I feel like TypeScript could reliably rewrite extensions of files that it knows exist, for statically defined specifiers. That's a much smaller scope than 'rewriting paths,' and it would solve this use case.

DanielRosenwasser

comment created time in 15 days

pull request commentjashkenas/coffeescript

Support import.meta and import.meta.*

this breaks indented property access

The same is true of new.target, so if we allow it for import.meta we should allow it there too.

I'm conflicted, as these aren't actually properties of an object the way that obj.prop is. import isn't an object, nor is it a function (even though it can appear like one e.g. import()). It's just a weird piece of syntax. Though I suppose the 'property access' is a part of grammar, and import.meta/new.target uses that grammar, so maybe it should follow that pattern?

aurium

comment created time in 15 days

issue commentjashkenas/coffeescript

Grammar, Nodes: Support import.meta and import.meta.*

I still do not understand many things, like the LOC(#)(...) helpers.

Those are for fixing location data. @helixbass is there somewhere that this is documented? If not we should do so, either in a comment where LOC is defined or in https://github.com/jashkenas/coffeescript/wiki/%5BHowTo%5D-How-parsing-works (or both).

aurium

comment created time in 15 days

push eventGeoffreyBooth/coffeescript-gulp

Aurélio A. Heckert

commit sha 5b0b501dfedc3b4793b3cc0f5d7461aacfeff43a

Don't miss a file when reseting without parser. Not only simpler, but also more tolerant to changes in the CoffeeScript project.

view details

Geoffrey Booth

commit sha 8eb2fbe56d2ffffcced9e5054a0c8acf2cb78a2e

Merge pull request #2 from aurium/patch-2

view details

push time in 15 days

PR merged GeoffreyBooth/coffeescript-gulp

Don't miss a file when reseting without parser.

Not only simpler, but also more tolerant to changes in the CoffeeScript project.

+4 -17

1 comment

1 changed file

aurium

pr closed time in 15 days

pull request commentGeoffreyBooth/coffeescript-gulp

Don't miss a file when reseting without parser.

I mean sure, although this file structure hasn't changed in at least five years. I've thought about refactoring nodes.coffee into a nodes folder where each class is its own file, but we would lose easy diffs in GitHub for all the PRs over time that have been opened against nodes.coffee. It's basically never going to change.

aurium

comment created time in 15 days

push eventGeoffreyBooth/coffeescript-gulp

Aurélio A. Heckert

commit sha d4f7cf26ded94ca197876e50d14b4fe7ad0a21b9

Sync FS before build Ensure the file changes will be accessible by the builder process.

view details

Aurélio A. Heckert

commit sha e199f835f95b09856ff059ae16f17934562cb5a0

Clear and Sync as one shell exec

view details

Geoffrey Booth

commit sha b915d9be8b6e87a8c727cf85ad5573c21208506a

Merge pull request #1 from aurium/patch-1

view details

push time in 15 days

PR merged GeoffreyBooth/coffeescript-gulp

Sync FS before build

Ensure the file changes will be accessible by the builder process.

+1 -1

3 comments

1 changed file

aurium

pr closed time in 15 days

pull request commentGeoffreyBooth/coffeescript-gulp

Sync FS before build

Ah. I work on a Mac, and I think the watch events are different per OS, so maybe the watching that Node or Gulp provides for Mac is just less problematic than what you're getting on your flavors of Linux.

aurium

comment created time in 15 days

issue commentjashkenas/coffeescript

Discussion: Barista, the Pluggable CoffeeScript

So something that's been discussed over the years (particularly by @lydell if I remember correctly) has been potentially refactoring out the need for jison. Basically look at grammar.coffee and the resulting parser.js; they're not one-to-one like what you'd get from compiling grammar.coffee into grammar.js. But parser.js is basically incomprehensible, a long machine-written switch statement; we would need some way of achieving the same result while still being human-comprehensible. And on top of that, it would need to be not significantly worse performance-wise than what we have now. This is no small task, but it would enable us to provide hooks at any step of the process: the lexing, the rewriting, the parsing, and the output generation (lexer.coffee, rewriter.coffee, grammar.coffee/parser.js, and then nodes.coffee). We could also get rid of the ugly hacks we currently have for “stowing away” extra data properties like comments “through” the parser, since we currently have so little control over the generated parser.js file, but would have total control once we dropped jison.

I say this up front because I think a basic requirement of any plugin architecture is that plugins need to be able to be loaded at runtime, without necessitating a rebuild of CoffeeScript in order to execute. Look at Babel for comparison: you can add and remove Babel plugins via a configuration, and that just causes Babel to load and execute a few more functions (or not) at specified points in its flow, but the Babel code itself never changes. CoffeeScript needs to be the same way. Especially considering how easy it is to screw up the grammar, creating grammars with inconsistencies that jison refuses to build, we need to keep the CoffeeScript core static.

I haven't dug through Babel's code, but that would probably be the blueprint for us to follow. I would assume our version would be something like this:

  1. Load source code for an input (such as a file)
  2. Run any registered plugins to transform source code just after load
  3. Lex the source code, including any additional lexer functions registered by plugins
  4. Rewrite the lexed tokens, including any additional rewriter functions registered by plugins
  5. Parse the rewritten tokens, including any additional grammar rules registered by plugins (this is why I mention dropping jison)
  6. Generate output JS and output AST, including any additional node classes registered by plugins
  7. Run any registered plugins to transform final output
  8. Save/emit output

This is what I'm familiar with from other contexts as a plugin hooks model: CoffeeScript provides a method where plugins register functions with hooks. Like the first hook I mention above could be called something like onSourceLoad and if a plugin defines a function to be run for that hook, CoffeeScript runs the custom function when CoffeeScript's flow gets to that point. A robust plugin architecture would support multiple plugins each registering functions for the same hook, and CoffeeScript running them each in turn. For example, a plugin could look like this:

# This plugin adds a naughty message at the bottom of every source file,
# by defining a function to be run within the `onSourceLoad` hook.
CoffeeScript.registerPlugin
  onSourceLoad: (source) -> "#{source}\nconsole.log 'not!'"

The anonymous function passed to onSourceLoad would be registered, and CoffeeScript would execute it at that point in its process. One thing to keep in mind is that CoffeeScript.compile is synchronous, and can't become async without that being a breaking change for any downstream tools, so all plugins need to also be synchronous. That shouldn't be a problem, I don't think (most things you'd want to do, like new grammars etc., should be sync operations) but it's something to keep in mind.

aurium

comment created time in 15 days

pull request commentnodejs/node

src: add support for top level await

Not that this needs to hold up this PR, but I wonder if we should investigate trying to make --print work in some fashion for ESM with top-level await. Like maybe capture Node's STDOUT and print that when all promises resolve, or something. I'm thinking that there are surely test runners out there that use --print, and yes they can refactor to use STDOUT or console.log(await fn()) (?) but if we can avoid pushing this refactoring necessity downstream onto the community we should.

devsnek

comment created time in 15 days

issue commentjashkenas/coffeescript

Proposal: Optional (pre-last) function arguments

Can you please include what the expected output JavaScript would be for your examples?

Also are there any ECMAScript proposals at any stage of the TC39 approval pipeline that overlap with this?

celalo

comment created time in 15 days

Pull request review commentnodejs/node

src: add support for top level await

 or when referenced by `import` statements within ES module code: * Files ending in `.js` when the nearest parent `package.json` file contains a   top-level field `"type"` with a value of `"commonjs"`. -* Strings passed in as an argument to `--eval` or `--print`, or piped to

--print for CommonJS input is sticking around, isn't it?

devsnek

comment created time in 16 days

pull request commentGeoffreyBooth/coffeescript-gulp

Sync FS before build

I've never heard of the sync shell command. Does it really make a difference?

aurium

comment created time in 17 days

Pull request review commentGeoffreyBooth/coffeescript-gulp

Sync FS before build

 execSyncOptions = buildAndTest = (done, includingParser = no) -> 	try 		execSync "clear; printf '\\033[3J'", execSyncOptions+		execSync 'sync', execSyncOptions
		execSync "clear; sync; printf '\\033[3J'", execSyncOptions
aurium

comment created time in 17 days

issue commentjashkenas/coffeescript

Grammar, Nodes: Support import.meta and import.meta.*

This is the Babel AST for import.meta:

image

So maybe using IDENTIFIER isn't terrible.

aurium

comment created time in 17 days

issue commentnodejs/modules

Loader Hooks

This has been something I've been thinking about as well. I think for a loader to handle both ESM and CommonJS files, it also needs to hook into require.extensions (at least for now). I'd like to proxy/override or wrap require.extensions['.js'] for extensions that should be handled similarly, but without necessarily having the “throw if this isn't ESM” check. I wonder if there's a not-terrible way to prevent that, aside from copying the source of require.extensions['.js'] into my code.

Another thing we might want to consider is making the ESM loader hooks simply the loader hooks, to apply to both CommonJS and ESM, finally replacing the deprecated require.extensions. I haven't given thought into how that would work in practice, but there are lots of use cases such as instrumentation where the loader should affect all files, not just ESM ones, and it's more work for loader authors to hook into both of Node's loaders in very different ways.

reasonablytall

comment created time in 17 days

Pull request review commentnodejs/node

module: better error for named exports from cjs

+import '../common/index.mjs';+import { rejects } from 'assert';++const fixtureBase = '../fixtures/es-modules/package-cjs-named-error';++const expectedRelative = 'The requested module \'./fail.cjs\' is expected to ' ++  'be of type CommonJS, which does not support named exports. CommonJS ' ++  'modules can be imported by importing the default export. For example:\n' ++  'import pkg from \'./fail.cjs\';\n' ++  'const {comeOn} = pkg;';

Generally the style is to include spaces when destructuring/importing, like how you have import { rejects } from 'assert' in this file (line 2).

How are you even getting the braces around comeOn in your code that generates this error?

MylesBorins

comment created time in 18 days

startedbmeck/extract-cjs-static-bindings

started time in 18 days

push eventGeoffreyBooth/node-loaders

Geoffrey Booth

commit sha 7f85962d3b6f96ced38854b57d722092c43c7877

Loader for CommonJS-style (legacy Node-style) specifier resolution, e.g. './file' for './file.js' and './folder' for './folder/index.js'

view details

push time in 18 days

pull request commentjashkenas/coffeescript

WIP: Output JS-compatible line numbers

I don't doubt there's an issue, but to fix it we need a minimal reproducible case. If you could provide as small an example as possible where the line numbers are wrong, either for stack traces or source maps, that would give us what we need to fix the bug.

helixbass

comment created time in 18 days

more