profile
viewpoint

alexisvincent/systemjs-hot-reloader 213

reloads your modules as needed so that you can have satisfyingly fast feedback loop when developing your app

aaronfrost/grunt-traceur 207

This is a grunt task for adding a grunt task to compiler ES6 JS into ES3 JS using Traceur Compiler

floatdrop/plugin-jsx 36

JSX loader plugin

guybedford/amd-loader 32

RequireJS loader plugin helper for transpiler and template plugins

guybedford/amdquery 6

A selector plugin for RequireJS with a dynamic query selector polyfill, supporting modular DOM utilities and builds.

GeoffreyBooth/node-esm-entry-points-proposal 2

How to support ESM syntax in entry points in Node.js

guybedford/babel 2

Turn ES6+ code into readable vanilla ES5 with source maps and more!

guybedford/amd-version 1

RequireJS semver-compatible versioning plugin

guybedford/babel-handbook 1

:blue_book: A guided handbook on how to use Babel and how to create plugins for Babel.

push eventguybedford/node

Guy Bedford

commit sha 7288f0326d4a0ae2c34bb759d58459f810a84634

fixup: linting

view details

push time in a day

push eventguybedford/node

Guy Bedford

commit sha 0e8e66940392967e1eeda53519bc98238c666490

module: remove experimental modules warnings

view details

push time in a day

PR opened nodejs/node

module: remove experimental modules warning ES Modules pending

This PR removes the experimental modules warnings for Node.js.

The modules group currently does not have consensus to remove the experimental warning for using ES modules in Node.js, but these timelines are currently being discussed.

This PR was separated out from https://github.com/nodejs/node/pull/31845. I would like if we could keep this PR open while discussion is happening, with the goal to eventually merge it when the appropriate timeline is agreed and met.

@nodejs/modules-active-members

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
  • [ ] 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. -->

+1 -20

0 comment

10 changed files

pr created time in a day

push eventguybedford/node

Guy Bedford

commit sha 93566e29aa83140ed8635decb3e3f334a801f8e4

module: remove experimental modules warnings

view details

push time in a day

push eventguybedford/node

Myles Borins

commit sha 1c2d77d3d9dd5753a96c0033265c5eeaf3531d00

2020-02-18, Version 12.16.1 'Erbium' (LTS) Notable changes: Node.js 12.16.0 included 6 regressions that are being fixed in this release **Accidental Unflagging of Self Resolving Modules**: 12.16.0 included a large update to the ESM implementation. One of the new features, Self Referential Modules, was accidentally released without requiring the `--experimental-modules` flag. This release is being made to appropriately flag the feature. **Process Cleanup Changed Introduced WASM-Related Assertion**: A change during Node.js process cleanup led to a crash in combination with specific usage of WASM. This has been fixed by partially reverted said change. A regression test and a full fix are being worked on and will likely be included in future 12.x and 13.x releases. **Use Largepages Runtime Option Introduced Linking Failure**: A Semver-Minor change to introduce `--use-largepages` as a runtime option introduced a linking failure. This had been fixed in master but regressed as the fix has not yet gone out in a Current release. The feature has been reverted, but will be able to reland with a fix in a future Semver-Minor release. **Async Hooks was Causing an Exception When Handling Errors**: Changes in async hooks internals introduced a case where an internal api call could be called with undefined causing a process to crash. The change to async hooks was reverted. A regression test and fix has been proposed and the change could re land in a future Semver-Patch release if the regression is reliably fixed. **New Enumerable Read-Only Property on EventEmitter breaks @types/extend** A new property for enumerating events was added to the EventEmitter class. This broke existing code that was using the `@types/extend` module for extending classses as `@types/extend` was attemping to write over the existing field which the new change made read-only. As this is the first property on EventEmitter that is read-only this feature could be considered Semver-Major. The new feature has been reverted but could re land in a future Semver-Minor release if a non breaking way of applying it is found. **Exceptions in the HTTP parser were not emitting an uncaughtException** A refactoring to Node.js interanls resulted in a bug where errors in the HTTP parser were not being emitted by `process.on('uncaughtException')`. The fix to this bug has been included in this release. PR-URL: https://github.com/nodejs/node/pull/31781

view details

Robert Nagy

commit sha 8ba7a2f889472d58478bf40b758d336b41af682b

http2: make compat finished match http/1 finished should true directly after end(). PR-URL: https://github.com/nodejs/node/pull/24347 Refs: https://github.com/nodejs/node/issues/24743 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Ujjwal Sharma <ryzokuken@disroot.org> Reviewed-By: Anatoli Papirovski <apapirovski@mac.com> Reviewed-By: James M Snell <jasnell@gmail.com>

view details

Shelley Vohr

commit sha 0c3c0e7184c4ca625148c14d61d8e9438a1b69f2

2020-02-18, Version 13.9.0 (Current) Notable changes: * async_hooks * add executionAsyncResource (Matteo Collina) #30959 * crypto * add crypto.diffieHellman (Tobias Nießen) #31178 * add DH support to generateKeyPair (Tobias Nießen) #31178 * simplify DH groups (Tobias Nießen) #31178 * add key type 'dh' (Tobias Nießen) #31178 * test * skip keygen tests on arm systems (Tobias Nießen) #31178 * perf_hooks * add property flags to GCPerformanceEntry (Kirill Fomichev) #29547 * process * report ArrayBuffer memory in `memoryUsage()` (Anna Henningsen) #31550 * readline * make tab size configurable (Ruben Bridgewater) #31318 * report * add support for Workers (Anna Henningsen) #31386 * worker * add ability to take heap snapshot from parent thread (Anna Henningsen) #31569 * added new collaborators * add ronag to collaborators (Robert Nagy) #31498 PR-URL: https://github.com/nodejs/node/pull/31837

view details

Myles Borins

commit sha 43fb664701d771c00595fa1c152cfca03b10a4fd

doc: fix missing changelog corrections There was a slight discrepancy between the build of 12.16.1 and what landed on 12.x. This was only a couple spelling errors that didn't get updated between machines I was working on. This change gets the changelog up to date with what went out in the release vs what is current on the 12.x release branch. PR-URL: https://github.com/nodejs/node/pull/31854 Reviewed-By: Shelley Vohr <codebytere@gmail.com> Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Richard Lau <riclau@uk.ibm.com>

view details

Shelley Vohr

commit sha 31290824de068eb4b282ab74829450b988ae225b

doc: fix notable changes for v13.9.0 PR-URL: https://github.com/nodejs/node/pull/31857 Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Tobias Nießen <tniessen@tnie.de> Reviewed-By: Myles Borins <myles.borins@gmail.com>

view details

Robert Nagy

commit sha 7c524fb092b143470795c8ca869de4654c728fe1

doc: fix Writable.write callback description Clarifies a userland invariant until a better solution can be found. Also moves a misplaced sentence from _write to write. Refs: https://github.com/nodejs/node/pull/31756 Refs: https://github.com/nodejs/node/pull/31765 PR-URL: https://github.com/nodejs/node/pull/31812 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

view details

Rich Trott

commit sha 822101f570478ffa15e4ed0e00cd0d67b9cc789e

meta: move eljefedelrodeodeljefe to emeritus eljefedelrodeodeljefe confirmed in email that moving to emeritus was fine at this time. PR-URL: https://github.com/nodejs/node/pull/31735 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Michaël Zasso <targos@protonmail.com>

view details

Joyee Cheung

commit sha e6c2277241e542cdf86475d71c5fdc581bd72025

vm: lazily initialize primordials for vm contexts Lazily initialize primordials when cross-context support for builtins is needed to fix the performance regression in context creation. PR-URL: https://github.com/nodejs/node/pull/31738 Fixes: https://github.com/nodejs/node/issues/29842 Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: David Carlier <devnexen@gmail.com>

view details

Gus Caplan

commit sha b8e41774d4287d128a40f7ecfecf170fe16fe9ed

fs: add fs/promises alias module PR-URL: https://github.com/nodejs/node/pull/31553 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de> Reviewed-By: Yuta Hiroto <hello@hiroppy.me>

view details

Harshitha KP

commit sha 2d3717ad847665de333c85e5239ad4e6a4c0eb95

worker: emit runtime error on loop creation failure Instead of hard asserting throw a runtime error, that is more consumable. Fixes: https://github.com/nodejs/node/issues/31614 PR-URL: https://github.com/nodejs/node/pull/31621 Reviewed-By: Anna Henningsen <anna@addaleax.net>

view details

Rich Trott

commit sha 1c4e984ed970612f129db2ba6f684311418ed3a2

test: remove common.PORT from test-net-write-callbacks.js Switch test-net-write-callbacks.js from common.PORT to a port assigned by the operating system. PR-URL: https://github.com/nodejs/node/pull/31839 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com>

view details

Rich Trott

commit sha cdac18519fd14df9ece958cf8e29b846f512656e

test: remove flaky designation for test-net-connect-options-port Closes: https://github.com/nodejs/node/issues/23207 PR-URL: https://github.com/nodejs/node/pull/31841 Fixes: https://github.com/nodejs/node/issues/23207 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: David Carlier <devnexen@gmail.com>

view details

Rich Trott

commit sha 82afd85a31ab7c8f931f0bb0b23e76570aceb46d

tools: update lint-md task to lint for possessives of Node.js Add a markdown lint rule to prohibit "Node.js'" and "Node.js's". Instead, of "Node.js' module system", use "the Node.js module system". Refs: https://github.com/nodejs/node/pull/31748#issuecomment-585087745 PR-URL: https://github.com/nodejs/node/pull/31862 Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

view details

Shelley Vohr

commit sha ae41049a760d55b5dcc20e137a7454e7c70415c4

doc: add note about ssh key to releases PR-URL: https://github.com/nodejs/node/pull/31856 Reviewed-By: Myles Borins <myles.borins@gmail.com> Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: James M Snell <jasnell@gmail.com>

view details

Michaël Zasso

commit sha cf0096104752607c7374a7f7297139e60b03c59d

tools: sync gyp code base with node-gyp repo PR-URL: https://github.com/nodejs/node/pull/30563 Reviewed-By: Ujjwal Sharma <ryzokuken@disroot.org> Reviewed-By: Christian Clauss <cclauss@me.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Rich Trott <rtrott@gmail.com>

view details

Rich Trott

commit sha 2f97e973ff540d2ae7de77482c631c06cc99c313

meta: move julianduque to emeritus julianduque confirmed in email that they can be moved to emeritus. PR-URL: https://github.com/nodejs/node/pull/31863 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Tobias Nießen <tniessen@tnie.de> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

view details

Vse Mozhet Byt

commit sha 2f23918ca5090417ad0e06be6ecce63553f17985

doc: update stream.pipeline() signature The `...transforms` parameter is optional. Refs: https://github.com/nodejs/node/blob/0875837417/lib/internal/streams/pipeline.js#L130-L132 Refs: https://github.com/nodejs/node/blob/e559842188/doc/api/stream.md#streams-compatibility-with-async-generators-and-async-iterators PR-URL: https://github.com/nodejs/node/pull/31789 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Robert Nagy <ronagy@icloud.com> Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

view details

Robert Nagy

commit sha 21bd6679ce150e193cacd4b1b6585928224f255a

stream: fix finished typo https://github.com/nodejs/node/pull/31509 introduced a slight typo. Fortunately this typo does not have big impact due to `isWritableFinished()`. Fixes: https://github.com/nodejs/node/pull/31509#discussion_r381809355 PR-URL: https://github.com/nodejs/node/pull/31881 Fixes: https://github.com/nodejs/node/issues/31509 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

view details

Tobias Nießen

commit sha 0e63a079e8f535e1d4f0398400c534b0b5772fa5

crypto: fix ieee-p1363 for createVerify Fixes: https://github.com/nodejs/node/issues/31866 PR-URL: https://github.com/nodejs/node/pull/31876 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

view details

Tobias Nießen

commit sha fa1fc6bf9f257f7365454dc7a28bb4cd4385919f

doc: fix anchor for ERR_TLS_INVALID_CONTEXT PR-URL: https://github.com/nodejs/node/pull/31915 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

view details

push time in a day

PR closed nodejs/node

module: disable conditional exports, self resolve warnings C++ ES Modules

This removes the experimental warnings for using conditional exports and package self resolution, while keeping these features as experimental.

Currently the warnings are inhibiting usage of conditional exports (see https://github.com/nodejs/node/issues/31819 and discussion at https://github.com/nodejs/modules/issues/485), such that removing them will allow us to get more usage feedback.

At this stage it seems worthwhile to remove the warnings at this point to ensure we have adequate usage and feedback prior to unflagging on the 12.x backport.

We discussed this as a possibility at the last meeting, but it still needs approval from the modules group, so marking as an agenda item there and blocked for landing.

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
  • [ ] 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. -->

+36 -6

6 comments

4 changed files

guybedford

pr closed time in a day

pull request commentnodejs/node

module: disable conditional exports, self resolve warnings

Landed in https://github.com/nodejs/node/commit/49ad16104fb467e5e76049950830b15f4793bc7c.

guybedford

comment created time in a day

push eventnodejs/node

Guy Bedford

commit sha 49ad16104fb467e5e76049950830b15f4793bc7c

module: disable conditional exports, self resolve warnings PR-URL: https://github.com/nodejs/node/pull/31845 Reviewed-By: Jan Krems <jan.krems@gmail.com> Reviewed-By: Geoffrey Booth <webmaster@geoffreybooth.com>

view details

push time in a day

create barnchguybedford/node

branch : remove-modules-warnings

created branch time in a day

push eventguybedford/node

Guy Bedford

commit sha fd2c05b2a980450f07d4c9f62243283cb71b2bb9

fixup: various

view details

push time in a day

Pull request review commentnodejs/node

module: disable conditional exports, self resolve warnings

 exports.importModuleDynamicallyCallback = async function(wrap, specifier) {       'ExperimentalWarning', undefined);     calledInitialize = true;

Thanks

guybedford

comment created time in a day

Pull request review commentnodejs/node

module: disable conditional exports, self resolve warnings

 const {   FunctionPrototypeBind,   ObjectSetPrototypeOf,-  SafeMap,+  SafeMap

Well spotted, added.

guybedford

comment created time in a day

push eventguybedford/node

Guy Bedford

commit sha 0760a082639338867bbfac1007cb32144d53593a

fixup: various

view details

push time in a day

pull request commentnodejs/node

module: disable conditional exports, self resolve warnings

I've gone ahead and removed the --experimental-modules flag removal from this PR.

guybedford

comment created time in a day

push eventguybedford/node

Guy Bedford

commit sha 98b1f93d23ad2a4de8ac2d29079c8ca887de14f1

fixup: disable experimental-modules flag removal

view details

push time in a day

issue commentnodejs/node

Disable __proto__

Note that the specific JSON issue quoted in the issue is blocked when enabling the --experimental-frozen-intrinsics flag, as it is not possible to write to any builtin __proto__ properties with this.

mcollina

comment created time in a day

issue commentWICG/import-maps

Split into fetch-maps and import-maps?

I liked the import: proposal, but making (for example) a CSS image go through an import map felt a little backwards.

@jakearchibald can you dig into this a bit more?

It does seem from this discussion that it would be useful to see import: moving forward for these use cases.

I'm not sure where the best place would be to continue with work on this though.... a direct HTML spec PR?

jakearchibald

comment created time in 2 days

issue commentWICG/admin

Process re forking a spec

Thanks @marcoscaceres for the feedback here. The intention is to get support for the depcache spec to be implemented in browsers as a new feature that is critical for using import maps in optimized production workflows.

Forking would be the simplest conceptual model, but if that's seen as messy we could go the extension route, and carefully indicate how it can integrate into import maps, it would be a little more intricate, but could still work.

I was under the impression from the charter that the fork model was encouraged for building out new features for re-merging, but if this extension model is preferable then I can write it up as a proposal like this too.

guybedford

comment created time in 2 days

pull request commentWICG/import-maps

Depcache spec and reference implementation

@domenic is there any way you could still be convinced this is a useful feature for this group to consider? Have you followed the issue discussion? I just haven't really heard a real argument from you for why you don't think this feature is suitable for this spec. Personally I see this as a critical feature for production modules, and first opened an issue on this problem three years ago. I'm happy to assist with spec work, implementation work and even creating a Chromium CL for it.

guybedford

comment created time in 2 days

issue commentWICG/import-maps

Proposal: Solving the waterfall problem with depcache

At Google we use a JavaScript framework that basically late loads event handlers, so having hundreds of even thousands of modules even after graph optimizations is possible.

You might find this useful: https://github.com/azukaru/progressive-fetching/blob/master/docs/dynamic-bundling/index.md

@iteriani @fenghaolw on a brief read, if I'm understanding correctly, this sounds like these modules are effectively AMD-like wrappers on the development modules. It's important that production modules are optimized based on module merging, such that the graph is much smaller, rather than individually wrapping each dev module with a function wrapper into the output chunk.

Does this involve some sort of server-side rendering or statically built map?

The same process that constructs the import map needs to know which dependencies to include in the import map. There is no reason to include dependencies which aren't loaded in the import map, Thus the optimal import map is one that is traced to just be what is necessary for the page load. This same tracing is the tracing needed to populate the depcache. It could be done dynamically or statically too.

guybedford

comment created time in 2 days

issue openedWICG/admin

Process re forking a spec

I've been encouraged to create a fork of the Import Maps spec given the feedback on the PR in https://github.com/WICG/import-maps/pull/210.

Per the charter this seems to be an encouraged process, yet there doesn't seem to be much info on the practical process. I would like to request some guidance on what is the proper way to manage this fork, with the goal to build interest and community around the new features and the intent to re-coordinate eventually.

Many thanks!

created time in 3 days

pull request commentWICG/import-maps

Depcache spec and reference implementation

@domenic I'm a little weary of aiming to get interest for a spec on top of a spec on top of a spec. The calls from such a depcache spec to WICG import maps will be quite hand-wavey with some complex interactions. In addition I did need to perform some injection and refactoring to the existing import maps algorithms. If you think this is the best approach, then I think a fork might be preferable, with the intent to re-merge. I would just like to see SystemJS and ES module shims built to spec work here on the optimization problems which is my primary interest as an implementor, so this seems like the right sort of route to me. Would you be ok with that?

guybedford

comment created time in 3 days

pull request commentnodejs/node

module: Refine and unify exports resolution error handling

The CITGM failures were tracked down to causes unrelated to this PR in https://github.com/nodejs/citgm/issues/785#issuecomment-590265182.

guybedford

comment created time in 3 days

issue commentnodejs/citgm

Failures on all platforms?

I can confirm that the eslint-plugin-jest failure is not #31625 either.

Rather, it is due to this bug which was patched on the Babel helper - https://github.com/babel/babel/pull/11006.

ronag

comment created time in 3 days

issue commentnodejs/citgm

Failures on all platforms?

So far, only the eslint-plugin-jest failure seems to be caused by #31625. I'm looking into the root cause still.

For the resolve case, it is doing require('module').builtinModules.forEach(m => require(m)) and seeing that require('fs/promises') is failing in its own implementation. This seems like an implementation failure in resolve itself since the addition of fs/promises, and can be ignored. (cc @ljharb, @devsnek)

ronag

comment created time in 3 days

pull request commentnodejs/node

module: recover on statCache failure

I believe the primary performance benefit of the stat cache actually comes from its ability to skip the misses more than knowing the hits. So any comprehensive solution here would actually be equivalent to just removing the stat cache for misses, and taking the major perf loss there.

Perhaps a Node.js flag --no-stat-cache or something like that?

benjamingr

comment created time in 3 days

issue commentnodejs/citgm

Failures on all platforms?

I'm looking into this now.

ronag

comment created time in 4 days

pull request commentnodejs/node

module: recover on statCache failure

Note this doesn't consistently support cases where an inner fallback is added after the fact. eg index.js being created where a previous index.json was being matched. Also for new nested layers of node_modules.

For these reasons perhaps treating it as a separate mode where the stat cache always rechecks for non-existent files in all its checks? I could get behind treating this as a default mode too even for consistency, although at this point that might be a difficult perf backtrack to make.

benjamingr

comment created time in 4 days

pull request commentWICG/import-maps

Depcache spec and reference implementation

@marcoscaceres thanks for the info here. I should already be a member I believe? I was sent an email to link my GitHub profile, which I did after posting this PR, but the check hasn't seemed to have updated. Any tips on further steps I can take here welcome.

guybedford

comment created time in 4 days

issue commentWICG/import-maps

Proposal: Solving the waterfall problem with depcache

@hiroshige-g

What are the benefits to include this depcache in import maps (e.g. compared to introducing a separate manifest file/mechanism)?

Your points are largely the main ones I think.

I could get still behind either approach, and this has been my opinion for a while. But this depcache proposal was posted out of my frustrations in getting nowhere after many continued preloading discussions with many different people.

Then my recent realization was that solving the waterfall problem for most web assets is simply not a primary concern for the web today due to the tree depth not being enough over human latency times like it is for modules.

@evmar's first comment was also about how a feature like depcache can itself bloat the page load. It would be a shame if the preload manifest itself were to become so full featured and verbose as to slow down page loads. Trying to flesh it out in https://github.com/WICG/import-maps/issues/208 also gives some idea of the verbosity to expect. What's nice about depcache is it is very much just solving the direct problem without trying to walk down the path of a "manifest to rule all manifests", which a preload spec risks, which seems like it could get lost in the weeds.

Is it conceptually good to place other similar things (e.g. other non-script-related preloading/dependency information) here? Or do you have criteria for what kind of things should be placed here together with depcache?

This is a difficult one indeed and an important question. I really don't know how to set those criteria other than on a very careful case by case basis.

I suppose the general guide should be it could extend but only to features that relate only to modules. Under this logic, module attributes could be a possibility but integrity, fetch options and credentials would not be suitable for import maps, and whether import maps could include execution / capability / module security options seems unclear.

guybedford

comment created time in 4 days

issue commentWICG/import-maps

Proposal: Solving the waterfall problem with depcache

@evmar thanks for the interesting feedback!

after compilation, which bundles related code together from the thousands of modules the code authors work with) the module map itself becomes large enough that it becomes a big part of your initial page load

I understand internal Google code development workflows are of course a little more intricate, but I think it is important to point out how module merging optimizations, now that they are well defined and well established, change the calculation. The production module graph should have much fewer module nodes (at least an order of magnitude) than the development module graph (the natural typical module combinations formed under your got-want-need scheme below played out across all clients).

That is, because you can't load the module map itself lazily, the larger it gets the larger your upfront cost gets.

I do think it will be worth supporting lazy loading of import maps at some point. If we split up the page load into:

  1. The modules that load on page load.
  2. The modules that we know may or may not be lazy loaded, depending on user interactions.
  3. The modules that we don't know will be lazy loaded.

An optimization if lazy loading of import maps is supported would be to separate import map (1) from import map(s) for (2), such that (1) is the initial import map, when after the page load, a new import map for (2) (or a few different ones) get lazily loaded in line with their priorities. This way, the initial page load is not slowed down by the growth of the mappings for lazy loads on the page.

This is starting to get out of scope for this thread, but handling how waiting for import maps works with lazy import map loading brings up important questions though, which I have tried to start considering in https://github.com/WICG/import-maps/issues/92#issuecomment-453578821. It may even be useful to define a platform callback for lazy loading of import maps when a mapping is not found enabling (3).

We moved to a system that requires a bit more server-side logic, where (following your initial example) the client makes a request like "I want lazy-feature, and I have already downloaded main and dep1".

One of the major benefits of depcache is that it can work for static server use cases. It would be a shame to have to tell users they can only get optimized delivery of their apps by using very specific server software, that must then have full knowledge of the module graph, and tying server software internals to application delivery. Server logic only really comes into its own for advanced cases of (2) and (3), and even then such work could even build on lazy import map loading too as described above.

@iteriani can you clarify what you mean by the url limit here:

we do end up downloading the module graph at some point once we exceed url limit for modules downloaded

Are you referring to reaching the limits of the module map size itself?

guybedford

comment created time in 4 days

delete branch WICG/import-maps

delete branch : depcache

delete time in 5 days

push eventguybedford/import-maps

Guy Bedford

commit sha 2bef7a5ee3de86a31b15abf074cf57c1b0019524

fixup test coverage

view details

push time in 5 days

create barnchWICG/import-maps

branch : depcache

created branch time in 5 days

PR opened WICG/import-maps

Depcache spec and reference implementation proposal

This PR implements the proposal in https://github.com/WICG/import-maps/issues/209, providing an optimal solution to the waterfall problem, while ensuring that import maps remain the source of truth for the graph and optimization for tools that generate them.

Let's keep proposal feedback to the issue, and direct spec feedback to this PR.

The approach I've implemented here is to effectively integrate the depcache check into fetch a single module script in the HTML spec, where the natural recursion between those steps and the preload steps perform the graph traversal, while naturally stopping due to the module map existence checks, avoiding the need for visited lists and such.

To support the new resolve a module specifier signature, I've separated out the top-level call to it from HTML from the base-level API-like call to it, called resolve import maps.

Any changes to the fetch a single module script signature in further refactoring can be applied equally to the depcache preload algorithm, although it is worth noting here that the script for depcache preloads doesn't exist at the time of the network request.

Feedback welcome, happy to keep working on this.

+251 -11

0 comment

16 changed files

pr created time in 5 days

issue openedWICG/import-maps

Proposal: Solving the waterfall problem with depcache

I'd like to propose a new "depcache" field in the import map, as an optimal solution to the waterfall problem for production optimization.

The core idea is to provide the ability for tools that generate import maps to also generate the metadata of the module graph as a sort of graph cache (dependency cache) at the same time - a map from URLs to their list of dependency specifiers.

With a populated depcache, as soon as a module is fetched, the depcache can be consulted, and the corresponding cached list of module dependencies preloaded immediately.

For example:

{
  "imports": {
    "main": "/main.js",
    "lazy-feature": "/lazy-feature.js,
    "dep1": "/lib/dep1.js",
    "dep2": "/lib/dep2.js"
  },
  "depcache": {
    "/main.js": ["dep"],
    "/lazy-feature.js": ["dep1", "dep2"]
  }
}

Say the main app loads "main" on startup. The depcache allows us to know that we need to also load /lib/dep1.js immediately. Both requests are made in parallel, possibly from the cache, the app thus working with zero latency waterfalls applying.

Later on a dynamic import('lazy-feature') is executed. At this point, the depcache can again be consulted, to see that /lazy-feature.js will import both dep1 and dep2. Since dep1 is already in the module map we do not need to send a new request, but then immediately send out just two requests - one for /lazy-feature.js and one for /lib/dep2.js, again getting lazy loading with full immediate parallel requests, without any duplication and supporting far-future caching.

Note that the unresolved dependency is included in the depcache. This allows the import map to remain the full source of truth for dependency resolution, and the depcache doesn't go stale despite resolutions changing.

The alternative as mentioned in the readme of this spec is a more general preloading spec. I have discussed with various spec authors and implementors the more general preload spec over the past year or two, and have found there to be a lack of interest - mostly I think because for most web resources, 2-3 round trips is the maximum due to the nature of HTML / CSS development. I would argue that modules are actually unique in having the problem of potentially N levels deep dependency trees, where N can be over 10, thus the latency problem between these depths does seem to me to be truly unique to modules.

This depcache proposal seems to me the simplest path forward right now to solve this optimization problem in a fully optimal way, given that a more general preload manifest is not getting traction, but I'm hoping by posting both this proposal and https://github.com/WICG/import-maps/issues/208, we can drive these conversations forward to ensure that this production optimization solution is tackled, as it really needs to be now for modules.

I'd like to also be able to move forward with this or a similar proposal in both SystemJS and ES Module Shims. Depcache as specified here has worked very well in previous versions of SystemJS for many years, and I'd like to start shipping this feature or similar in both projects again soon as a critical performance necessity right now for users of these projects today. Both projects aim to track these standards so hopefully we can continue these discussions and continue to solve these problems optimally.

created time in 5 days

push eventguybedford/import-maps

Guy Bedford

commit sha fe86b4d9ed37eb35a88d8506c22c45bceec85012

depcache spec and reference implementation proposal

view details

push time in 5 days

issue commentWICG/import-maps

Driving work on a preload spec

@MylesBorins I tend to think these optimization problems can be tackled by both a preloading technique and web bundles. Trying web bundles to being the only solution space seems somewhat restrictive to me. I'd like to avoid going down this rabbit hole much further if you don't mind, but "overlap" is just the word to consider here - web bundles are great for base application delivery, but aren't so great at dealing with possible duplicate content delivered when lazy loading different plugins / sections for an app that have shared depedencies, unless the server itself is performing active content negotiation, ruling out static site use cases.

guybedford

comment created time in 5 days

push eventguybedford/import-maps

Guy Bedford

commit sha 751ef092ba401b77a94f7700fe9a680d5057db71

depcache spec and reference implementation proposal

view details

push time in 5 days

push eventguybedford/import-maps

Guy Bedford

commit sha e73796e7c8a948f3c95a90dbafc14c248bd639c0

depcache spec

view details

push time in 5 days

create barnchguybedford/import-maps

branch : depcache

created branch time in 5 days

issue openedguybedford/es-module-shims

Proposal: An experimental depcache implementation

I recently opened this issue on the import maps specification to again discuss handling the waterfall problem of module loading - https://github.com/WICG/import-maps/issues/208.

Problem

It is common in npm workflows to possibly have dependency trees with depths of up to 10 modules deep.

Import maps bring these kinds of workflows to the browser, where unlike other resources which typically cap out at 2-3 extra round trips of latency (eg page.html -> style.css -> common.css -> header.png). There's a natural upper bound for most resources because there aren't really development patterns that increase the depth here.

But with modules, the depth in theory can have no limit. 10 extra round trips becomes a second of latency in some areas. If we get to depths of 20 / 30 modules in a tree, that becomes worse even with geographic edge caching.

Proposal

SystemJS successfully solved this problem a long time ago with depcache, and it can map to import maps quite easily.

The concept is that the import map is generated by some tool on the server that knows about all the modules. So that tool can also inject what is called a "dependency cache". Basically just letting the system know what imports each module has.

This information is enough to flatten the full tree and request all modules in parallel.

The suggested semantics are the following:

<script type="importmap">
{
  // standard import map properties
  "imports": { ...imports... },
  "scopes": { ...scopes... }

  // proposed property:
  "depcache": {
    "/module.js": [
       "pkgimport",
       "./relimport.js",
       "//url.com/import.js"
    ],
    "/module2.js": [...]
  }
}
</script>

This proposal works well with dynamic import and lazy loading - if /module2.js is lazily imported dynamically (say a plugin system), then since we already know all its dependencies upfront we can download them in parallel.

Given that import maps aren't driving any work on this, and I've tried unsuccessfully over the past year to engage specification authors on working on a solution to this problem, it may be time to just implement the solution in es-module-shims.

This will provide the feature and benefits to users.

At the same time, a specification for depcache can be brought to the import maps spec, and whatever that turns into having this experimental feature in es-module-shims can help drive the process.

Further suggestions / thoughts on the above very welcome, otherwise I think the time has come to make a move here.

created time in 6 days

issue commentsystemjs/systemjs

ERROR: TS2306 ... is not a module for type definitions SystemJS 6.1

Thanks for posting, does that simple correction you included fix the issue?

If you'd like to make that PR to type types that would be great.

OZ79

comment created time in 6 days

push eventzeit/ncc

Guy Bedford

commit sha 17f706b96534283962a1ff12178d228b3a9b87b7

Update src/cli.js Co-Authored-By: Steven <steven@ceriously.com>

view details

push time in 6 days

Pull request review commentzeit/ncc

Add support for .cjs outputs

 async function runCmd (argv, stdout, stderr) {          outDir = outDir || resolve("dist");         mkdirp.sync(outDir);-        // remove all existing ".js" files in the out directory+        // remove all existing ".js", ".mjs" and ".cjs" files in the out directory         await Promise.all(           (await new Promise((resolve, reject) =>-            glob(outDir + '/**/*.js', (err, files) => err ? reject(err) : resolve(files))+            glob(outDir + '/**/*.(js|mjs|cjs)', (err, files) => err ? reject(err) : resolve(files))

Sure, until we add support for mjs that makes sense. Added.

guybedford

comment created time in 7 days

push eventzeit/ncc

Guy Bedford

commit sha e99224fa729b1c80bc704c182d6373c97ecc24f6

only clear cjs and js

view details

push time in 7 days

issue commentGoogleChromeLabs/worker-plugin

worker_threads compatibility?

@developit that seems like a good approach. It's worth noting though that there are a lot of differences between worker threads and native workers. See eg https://github.com/nodejs/node/issues/30682#issuecomment-561010832.

The simple difference from your example is "./my-worker.js" doesn't work as a worker reference in Node.js as it is a process.cwd-relative path not a module-relative URL.

The list is basically:

  1. Use new URL('./worker.js', import.meta.url) as the input to the Worker call (as soon as https://github.com/nodejs/node/pull/31664 lands)
  2. worker.addEventListener is worker.on in Node.js
  3. self.addEventListener in a worker is require('worker_threads').parentPort.on in Node.js
  4. In Node.js worker event data e.data must be accessed without the .data part.

I think this is simply too much compat friction for your approach mentioned above to work for any user that doesn't have half a day to mess around with this stuff....

guybedford

comment created time in 7 days

push eventzeit/ncc

Guy Bedford

commit sha 14a0482b4633ddea309af5756cc9c6b0809c17a2

simplify diff

view details

push time in 7 days

push eventzeit/ncc

Guy Bedford

commit sha f50ff447db72e809c16cfb77c305699f478f6423

fixup notfound lookup

view details

Guy Bedford

commit sha 03e27761ee39fe73202bc28a91664e1892c4f08b

sourcemap fixes

view details

push time in 7 days

push eventzeit/ncc

Guy Bedford

commit sha ca219688b4de86f30b148084bc868a2c5ceda9e5

include fixtures files

view details

push time in 7 days

Pull request review commentzeit/ncc

Add support for .cjs outputs

 async function runCmd (argv, stdout, stderr) {       let startTime = Date.now();       let ps;       const buildFile = eval("require.resolve")(resolve(args._[1] || "."));+      const ext = buildFile.endsWith('.cjs') ? '.cjs' : '.js';

As mentioned above - yes this can easily extend to .mjs, but requires the support for an ES module output first, which should probably be a separate flag in its own PR.

guybedford

comment created time in 7 days

Pull request review commentzeit/ncc

Add support for .cjs outputs

 $ ncc build input.js -o dist  Outputs the Node.js compact build of `input.js` into `dist/index.js`. +> Note: If the input file is using a `.cjs` extension, then so will the corresponding output file.+> This is useful for packages that want to use `.js` files as modules in native Node.js using+> a `"type": "module"` in the package.json file.

Supporting .mjs would actually be a separate feature, because it would involve changing the module format of the output file. Let's continue to track this in https://github.com/zeit/ncc/issues/512.

guybedford

comment created time in 7 days

issue openedzeit/ncc

Outputting an ES module / .mjs build

We should be able to enable a --module flag or similar at this point that enables outputting an ES module instead of a CommonJS build.

created time in 7 days

push eventzeit/ncc

Guy Bedford

commit sha 0608e3c87657b47bb772c304f6a4edb1c9089d27

include cjs variations of not found and sourcemap register

view details

push time in 7 days

issue commentnodejs/modules

Node 13.9.0 blocks the use of npm scripts together with --loader funcionality

Note it would still be an option for us to allow files without an extension for the Node.js CLI entry point only, as we had previously, which was specially implemented before for backwards compatibility cases like this.

sla100

comment created time in 7 days

issue commentnodejs/modules

Node 13.9.0 blocks the use of npm scripts together with --loader funcionality

You should be able to work around this by implementing your custom loader to support a get_format hook which allows extensionless files.

Something like:

import { extname } from 'path';
export async function getFormat(url, context, defaultGetFormat) {
  if (!extname(url.pathname)) {
    return {
      format: 'module'
    };
  }
  return defaultGetFormat(url, context, defaultGetFormat);
}
sla100

comment created time in 7 days

push eventzeit/ncc

Guy Bedford

commit sha f9fdb15de416b1d9e31bd454e918a47890dceffb

add support for .mjs and .cjs outputs

view details

push time in 7 days

push eventzeit/ncc

Guy Bedford

commit sha 294b8b3200867016031b643c6195b58eca072b8e

add support for .cjs outputs

view details

push time in 7 days

PR opened zeit/ncc

Reviewers
Add support for .mjs and .cjs outputs

This PR adds support for .cjs output files from ncc, when the input file is using the .cjs extension.

As included in the readme comment, this is useful for packages setting "type": "module" in the package.json that want '.js' files in the package to be able to be modules, and thus need the '.cjs' extension on all CommonJS files.

+39 -23

0 comment

4 changed files

pr created time in 7 days

create barnchzeit/ncc

branch : cjs-ext

created branch time in 7 days

pull request commentsystemjs/systemjs

fix: cleaning up registerRegistry after instantiate

Another alternative that might work is simply setting registerRegistry[name] = null, where we can then check registerRegistry.hasOwnProperty(name) for the resolver.

That might save some code and minor perf.

k-j-kim

comment created time in 7 days

Pull request review commentsystemjs/systemjs

fix: cleaning up registerRegistry after instantiate

    function setRegisterRegistry(systemInstance) {     systemInstance.registerRegistry = Object.create(null);+    systemInstance.nameRegistry = [];

It would be faster to use an object here, since arrays are O(n) lookup.

k-j-kim

comment created time in 7 days

issue commentsystemjs/systemjs

System.delete does not delete entry from registerRegistry

Yeah that's a problem... I'm open to suggestions then.

It's worth noting that named registration is considered a deprecated feature.

k-j-kim

comment created time in 7 days

pull request commentnodejs/node

module: prevent builtins from resolving from disk

That npm didn't originally block packages like process from being published as a package in the first place is the really unfortunate oversight here.... (which now has 10 million downloads per week - https://www.npmjs.com/package/process).

devsnek

comment created time in 7 days

issue commentsystemjs/systemjs

Provide ES module output

Unfortunately window.System needs to be defined for the module format itself to work since System.register assumes window.System.register exists.

SystemJS should support being imported as a module fine through import 'systemjs' just not with any exports.

Jack-Works

comment created time in 7 days

issue commentsystemjs/systemjs

System.delete does not delete entry from registerRegistry

The act of a module being loaded from the register registry should delete the entry in the register registry as it uses it. That it isn't seems like a bug to me yes, and rather than patching the delete function, a PR to the named register extension to delete the entries as it uses them would be great.

k-j-kim

comment created time in 7 days

pull request commentnodejs/node

module: prevent builtins from resolving from disk

@devsnek unfortunately I don't think we can break Webpack even on semver major.

devsnek

comment created time in 7 days

pull request commentnodejs/node

module: prevent builtins from resolving from disk

@devsnek it seems like this on its own in Webpack is enough to block this PR actually - require.resolve('process/browser.js').

devsnek

comment created time in 7 days

pull request commentzeit/ncc

Support `.js` imports from typescript

Ok, I've included a guard that this extension fallback only happens when importing from another TypeScript file, and I also added a test here for nested imports of .ts.

guybedford

comment created time in 7 days

Pull request review commentzeit/ncc

Support `.js` imports from typescript

 module.exports = (           if (!err.missing || !err.missing.length)             return callback(err);           // make not found errors runtime errors

Fixed the comments.

guybedford

comment created time in 7 days

push eventzeit/ncc

Guy Bedford

commit sha 8ab5f6bfbe5daf098d750b696064486f32bb4897

fixup comments

view details

push time in 7 days

push eventzeit/ncc

Guy Bedford

commit sha f8a73e09378e898bf8f016bd962d72f3ecb7da74

guard on tsx? parent only

view details

push time in 7 days

pull request commentzeit/ncc

Support `.js` imports from typescript

@styfle thanks for the quick review. Yes ideally node-file-trace would include the same (if it doesn't support it already), and this is something I'd recommend checking in other workflows too.

guybedford

comment created time in 7 days

Pull request review commentzeit/ncc

Support `.js` imports from typescript

 module.exports = (           if (!err.missing || !err.missing.length)             return callback(err);           // make not found errors runtime errors

This feature still applies separately - since if the path isn't found, we always ensure it is a runtime check.

This has been branched now as for backwards compat I wanted to first check the webpack resolver against ./file.js before trying ./file so it's effectively doing two resolutions checks on the fallback.

That said, I haven't guarded this by ensuring the parent is definitely a tsx? module.... let me add that.

guybedford

comment created time in 7 days

push eventzeit/ncc

Guy Bedford

commit sha 220606f075fdc3c9e4d77cb784e0fe75e3a584a4

support .js ts imports

view details

push time in 7 days

push eventzeit/ncc

Guy Bedford

commit sha bec3baa45cd2d4881fd185d32511269925099613

support .js ts imports

view details

push time in 7 days

issue closedTypeStrong/ts-loader

Supporting '.js' imports

TypeScript are currently recommending that the best way to handle Node.js ES module support output is to use explicit .js extensions in the imports, even between TypeScript files (see https://github.com/microsoft/TypeScript/issues/16577#issuecomment-309169829):

main.ts

import dep from './dep.js';

dep.ts

export default 'dependency';

This is the only pattern that guarantees that extensions are included in a tsc compilation, making the output work in Node.js modules.

I just tried this out with ts-loader in ncc, and am getting that this is not supported.

I think it would be ideal if this project could follow that same pattern.

closed time in 7 days

guybedford

issue commentTypeStrong/ts-loader

Supporting '.js' imports

Closing as a non-bug since it appears this is working correctly after all!

guybedford

comment created time in 7 days

IssuesEvent

issue closedzeit/ncc

Supporting .js imports for TypeScript

I just created an issue for this on the ts-loader project at https://github.com/TypeStrong/ts-loader/issues/1056. I think this would be a useful feature to allow better module compat.

closed time in 7 days

guybedford

issue commentzeit/ncc

Supporting .js imports for TypeScript

Closing as a non-bug since it appears this is working correctly after all!.

guybedford

comment created time in 7 days

PR opened zeit/ncc

Reviewers
Support .js ts imports

This resolves https://github.com/zeit/ncc/issues/508 in allowing the pattern for TypeScript code in using .js extensions to reference other TypeScript files.

This is currently recommended by the TypeScript team (https://github.com/microsoft/TypeScript/issues/16577#issuecomment-309169829) as an approach for writing TypeScript that will include the file extensions in the output files when using tsc manually, resulting in Node.js and browser compatibility for the output.

With this PR, ncc doesn't have to break enabling this workflow for users, while remaining backwards compatible with the previous behaviour so it would be fine to release this as a minor.

+231 -2

0 comment

8 changed files

pr created time in 7 days

push eventzeit/ncc

Guy Bedford

commit sha e1694b0f89aeebad98572d0ea47c50361e6d9f01

support .js ts imports

view details

push time in 7 days

create barnchzeit/ncc

branch : ts-exts

created branch time in 7 days

PR closed TypeStrong/ts-loader

feat: support .js extensions from .ts files

Thanks for the quick response on https://github.com/TypeStrong/ts-loader/issues/1056 - I went ahead and put together the PR.

The gist of the logic is this - when importing a file through the .ts resolver, TypeScript will strip .js extensions such that they can still resolve to .ts files or .js files depending on what exists on the file system.

+100 -1

1 comment

12 changed files

guybedford

pr closed time in 7 days

pull request commentTypeStrong/ts-loader

feat: support .js extensions from .ts files

Hmm, actually I did some more digging and I believe this test is passing just fine without this change.... so I think we are good, it's just ncc support that is needed explicitly.

guybedford

comment created time in 7 days

PR opened TypeStrong/ts-loader

feat: support .js extensions from .ts files

Thanks for the quick response on https://github.com/TypeStrong/ts-loader/issues/1056 - I went ahead and put together the PR.

The gist of the logic is this - when importing a file through the .ts resolver, TypeScript will strip .js extensions such that they can still resolve to .ts files or .js files depending on what exists on the file system.

+100 -1

0 comment

12 changed files

pr created time in 7 days

create barnchguybedford/ts-loader

branch : ts-exts

created branch time in 7 days

fork guybedford/ts-loader

TypeScript loader for webpack

fork in 7 days

issue openedzeit/ncc

Supporting .js imports for TypeScript

I just created an issue for this on the ts-loader project at https://github.com/TypeStrong/ts-loader/issues/1056. I think this would be a useful feature to allow better module compat.

created time in 9 days

issue openedTypeStrong/ts-loader

Supporting '.js' imports

TypeScript are currently recommending that the best way to handle Node.js ES module support output is to use explicit .js extensions in the imports, even between TypeScript files (see https://github.com/microsoft/TypeScript/issues/16577#issuecomment-309169829):

main.ts

import dep from './dep.js';

dep.ts

export default 'dependency';

This is the only pattern that guarantees that extensions are included in a tsc compilation, making the output work in Node.js modules.

I just tried this out with ts-loader in ncc, and am getting that this is not supported.

I think it would be ideal if this project could follow that same pattern.

created time in 9 days

issue openednpm/make-fetch-happen

[FEATURE] Cache 3xx redirects

What / Why

It would be great if the same caching that is provided for content responses could be included for redirect responses as well using the same cache control header rules for the redirect response itself.

When

Currently there is no cache or offline support for redirect requests as far as I can tell.

created time in 9 days

Pull request review commentnodejs/node

module: disable conditional exports, self resolve warnings

 class Loader {   }    async resolve(specifier, parentURL) {+    if (parentURL instanceof URL)

Agreed. Yeah it seems like it's not clear enough to be a simple change - ok I've reverted the URL change for now.

guybedford

comment created time in 9 days

push eventguybedford/node

Guy Bedford

commit sha 0ce99ad8884d61cd681c34f83fd405fede4ca029

module: disable conditional exports, self resolve warnings

view details

push time in 9 days

Pull request review commentnodejs/node

module: disable conditional exports, self resolve warnings

 class Loader {   }    async resolve(specifier, parentURL) {+    if (parentURL instanceof URL)

I had a look at what the fs functions do and adopted the same approach in using the searchParams symbol as the check as in https://github.com/nodejs/node/blob/master/lib/internal/url.js.

The alternative is to use the toString() method by default instead of strict argument checking. I'm tempted to say that might be more in line with web behaviour (eg window.location = { toString () { return 'https://www.google.com' } }). I also know URL as an API argument is discouraged in the URL spec (despite this being something everyone does!).

Open to feedback either way here further, or splitting it out if that is deemed better. I'm just trying to hit my PR budget for this month :P

guybedford

comment created time in 9 days

push eventguybedford/node

Guy Bedford

commit sha 58de9b46b80fd3e48f5faf9db8101930a6493fc4

module: package "exports" error refinements PR-URL: https://github.com/nodejs/node/pull/31625 Reviewed-By: Jan Krems <jan.krems@gmail.com>

view details

Guy Bedford

commit sha 06ebc32305f6a59f6f2860fb175c75da58c8d159

module: disable conditional exports, self resolve warnings

view details

Guy Bedford

commit sha fd957a001f857a8adc74b7825090518fcf4ab695

remove experimental ES module warning

view details

Guy Bedford

commit sha 5c339fd8d8faa63a6566e2cd7496052d3fb9c7d0

refine URL check

view details

push time in 9 days

push eventguybedford/node

Guy Bedford

commit sha 38eef00bb1d9970be9113c20b916bb9fc9837d34

refine URL check

view details

push time in 9 days

pull request commentnodejs/node

module: Refine and unify exports resolution error handling

Landed in https://github.com/nodejs/node/commit/58de9b46b80fd3e48f5faf9db8101930a6493fc4.

guybedford

comment created time in 9 days

PR closed nodejs/node

module: Refine and unify exports resolution error handling C++ ES Modules lib / src modules-agenda

This PR includes a number of refinements to the error handling of exports resolutions in the ES module resolver:

  • Exports resolution error messages and codes are fully unified between the CJS and ESM resolver implementations, with the only difference that the ESM resolver errors include an imported from ... part since they don't have natural error stacks like require() does.
  • The MODULE_NOT_FOUND errors from "exports" resolution are split up into three separate errors: ERR_INVALID_PACKAGE_TARGET, ERR_INVALID_MODULE_SPECIFIER, and ERR_PACKAGE_PATH_NOT_EXPORTED. Previously we wanted to try to maintain unification on the MODULE_NOT_FOUND error, but we already have ERR_INVALID_PACKAGE_CONFIG and ERR_INVALID_MODULE_SPECIFIER to track, such that this unification has become restricting I think.
  • ERR_INVALID_PACKAGE_TARGET is thrown whenever the exports resolution value in the package.json itself is invalid. This includes values that fail validation like invalid:url or backtrack below the package boundary like ../../../outside.
  • ERR_INVALID_MODULE_SPECIFIER is extended to throw for cases like "exports": { "./sub/": "./sub/" } where the user attempts to require eg pkg/sub/../../../asdf or pkg/sub/node_modules/... etc. The error thus distinguishes that the fault is with the requestor, not the package.json itself.
  • ERR_PACKAGE_PATH_NOT_EXPORTED is thrown whenever trying to import an export from a package that is not defined. These are effectively the encapsulation errors for "exports".

The main semantic changes in this PR are then the following:

  1. Conditional exports fallbacks (as introduced by logical conditional exports ordering in https://github.com/nodejs/node/pull/31008) are then restricted only to apply to ERR_PACKAGE_PATH_NOT_EXPORTED errors, and not the other classes of errors. This much more clearly ensures that only those conditions not defined to match fall through. For a contrived example: "exports": { "node": { "node": "not:valid" }, "default": "./valid.js" } would before this PR always return the valid.js path, but after this PR always throw an ERR_INVALID_PACKAGE_TARGET error for the not:valid path. On the other hand, "exports": { "node": { "never": "./never.js" }, "default": "./valid.js" } would fall through the "never" path fine. Array fallbacks continue to fall back on the validation errors though as designed.
  2. Whenever "exports" is set, we no longer fall back to trying the main. If there is no main defined by exports - either because there is no "." entry, or because there is no conditional resolution for the "." entry (eg "exports": { "never": "./never.js" }), the ERR_PACKAGE_PATH_NOT_EXPORTED error will immediately throw without doing any "main" or "index.js" lookups. This makes "exports" exhaustive in its definition of the package resolution, and simplifies the error handling consistency for exports in turn.

Since its original proposal, "exports" has very much turned into a full replacement for "main". Having self-resolve entirely reliant on this field being set is also in line with this. I understand (2) may be the most controversial part of this PR with the biggest user-facing consequences, so I expect we should discuss this further in the next meeting. This PR can be adjusted further based on any resolutions. The logic connects around the error handling hence the monolith here.

In addition, this PR fixes https://github.com/nodejs/node/issues/31510 and the incorrect use of XOR instead of bit shift described in https://github.com/nodejs/node/pull/31008#pullrequestreview-352499949.

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. -->

+332 -220

6 comments

10 changed files

guybedford

pr closed time in 9 days

push eventnodejs/node

Guy Bedford

commit sha 58de9b46b80fd3e48f5faf9db8101930a6493fc4

module: package "exports" error refinements PR-URL: https://github.com/nodejs/node/pull/31625 Reviewed-By: Jan Krems <jan.krems@gmail.com>

view details

push time in 9 days

more