New TC39 Modules Proposals  ## Metadata - Author: [[OpenJS Foundation]] - Full Title: New TC39 Modules Proposals - Category: #articles - Document Note: --- tags: [#tc39, #javascript, #nodejs] - #tc39 - #javascript - #nodejs Author: TC39 presenter (representing Node.js and European.js Foundation) Source: YouTube - "New TC39 Modules Proposals" Reference: [Watch on YouTube](https://www.youtube.com/watch?v=1Gtzx7_IN4w) date created: 2025-08-24 03:00 --- # Title: New TC39 Modules Proposals and Node.js Implications ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) --- ## 📝 Summary: The presentation outlines **new proposals for JavaScript modules at TC39** and their direct implications for **Node.js**. Collaboration between Node.js and TC39 is essential to ensure compatibility and influence specification design. Key topics include **import attributes**, **import reflection**, **module expressions**, **deferred module evaluation**, and the **assets proposal**. These proposals aim to improve module flexibility, security, performance, and developer ergonomics. The talk emphasizes timely feedback and cross-runtime cooperation, warning that late engagement risks leaving Node.js users with suboptimal outcomes. --- ## 📖 Main Content: The evolving TC39 module proposals are shaping how JavaScript handles imports, bundling, and modularization. Node.js developers must stay engaged with these changes to avoid repeating past mistakes seen during the ES module adoption process. **Highlights:** - **Import attributes**: More robust JSON and typed imports with evolving syntax (`with` vs `assert`). - **Import reflection**: Ability to inspect and virtualize modules for testing, bundling, and security analysis. - **Module expressions & declarations**: Inline, first-class modules enabling improved worker workflows and native bundling. - **Deferred evaluation**: Lazy loading in ES modules to improve performance, akin to CommonJS patterns. - **Assets proposal**: Simplified resource handling integrated into the loader pipeline. - **Security benefits**: Modular systems reduce injection risks by eliminating arbitrary string-based imports. - **Process**: Some proposals are reaching stage 3 (e.g., import reflection), with implementation imminent. ### 🗒️ Notes - [00:00](https://www.youtube.com/watch?v=1Gtzx7_IN4w&t=0) Node.js must collaborate with TC39 to influence module updates. - [02:38](https://www.youtube.com/watch?v=1Gtzx7_IN4w&t=158) Import Reflection → virtualization, tooling friendliness, security, testing benefits. - [05:28](https://www.youtube.com/watch?v=1Gtzx7_IN4w&t=328) Module Expressions & Declarations → inline static modules, improved bundling, worker support. - [07:55](https://www.youtube.com/watch?v=1Gtzx7_IN4w&t=475) Deferred module evaluation + assets proposal for performance and simplification. - [10:08](https://www.youtube.com/watch?v=1Gtzx7_IN4w&t=608) Loader pipeline phases evolving; deferred eval integrated deeply. - [12:44](https://www.youtube.com/watch?v=1Gtzx7_IN4w&t=764) Modular systems → static verification, multi-instantiation, better testing, fewer security issues. - [16:09](https://www.youtube.com/watch?v=1Gtzx7_IN4w&t=969) Stage three targeted for import reflection & module expressions; implementation imminent. - [19:13](https://www.youtube.com/watch?v=1Gtzx7_IN4w&t=1153) User review crucial → feedback too late at stage 3 risks poor adoption. --- ## 📖 References: - TC39 Proposals Tracker: [GitHub repo](https://github.com/tc39/proposals) - Node.js & Modules: [Node.js Modules documentation](https://nodejs.org/api/modules.html) - WinterCG collaboration: [WinterCG GitHub](https://github.com/wintercg/proposals) --- ## 🗣️ Paraphrase: 1. **Original**: "Node.js needs to collaborate and keep involved in the TC39 process and not ignore it." **Paraphrase**: The Node.js community must actively participate in TC39 discussions to shape modules, avoiding past mistakes of late engagement. 2. **Original**: "Deferred module evaluation is a way to optimize performance without making modules too dynamic." **Paraphrase**: Lazy loading lets modules save execution time while maintaining a static, predictable structure, balancing flexibility with safety. --- ## 📰 Newsletter: 🆕 **JavaScript Modules: Big Changes Ahead** If you thought JavaScript modules were settled, think again! TC39 is pushing forward with **new proposals** that will directly affect Node.js developers. Among the highlights: - **Import Reflection** → better security & testing. - **Module Expressions & Declarations** → inline modules + first-class bundling. - **Deferred Evaluation** → faster startup times with lazy loading. - **Assets Proposal** → streamlined resource handling. These features are edging toward **stage 3**, meaning real-world implementation could be just months away. Node.js must stay engaged with TC39 to ensure developer needs are addressed. 👉 [Watch the full talk](https://www.youtube.com/watch?v=1Gtzx7_IN4w) to catch the roadmap. --- ## ✅ Action Items: - Emphasize **community engagement** in standards to avoid "too late" feedback loops. - Map proposals to **developer education modules** for onboarding. - Link to **security benefits** of modular systems in WordPress + OSS governance. - Frame OSPO strategy around **early engagement in cross-runtime governance (WinterCG, TC39)**. - Highlight alignment between **open governance** in JS modules and WordPress’s contributor-driven evolution. --- ## 🧪 Hypotheses: - Early Node.js engagement in TC39 leads to fewer breaking changes and better adoption. - Import reflection improves testing reliability compared to current module tools. - Deferred evaluation reduces startup latency in high-scale Node.js apps. ### 📊 Methodology: - Benchmark deferred evaluation in Node.js apps vs. CommonJS lazy patterns. - Security audits comparing import reflection vs. dynamic imports. - Surveys of Node.js contributors on involvement in TC39. ### ❓ Questions: - How can Node.js maintain influence in TC39 despite resource limits? - Should WinterCG act as a unifying body for cross-runtime feedback? - What safeguards are needed to prevent regressions in modular security? ### 🔮 Future Research: - Long-term performance effects of deferred module evaluation. - Governance frameworks for runtime-standard collaborations. - Developer experience studies on module expressions + declarations. ### 💡 Implications: - Standards shape runtime adoption → governance must be proactive. - Improves OSS ecosystem **security + reliability**. - Creates **educational opportunities** in explaining evolving module systems. --- ## 🧠 Learning Styles Assessment: - **Visual**: Slides mentioned; add diagrams showing loader pipeline. - **Aural**: Video talk supports auditory learners. - **Verbal**: Technical explanation strong, could add analogies. - **Kinesthetic**: Lacks code labs; suggest interactive demos. - **Logical**: Strong logical flow in proposals. - **Social**: Q&A fosters group learning. - **Solitary**: Few prompts for reflection; could add. - **Naturalistic**: No connections; could use system analogies (ecosystems). --- ## 📊 Accessibility Assessment: - Transcript present, good for screen readers. - Needs **alt-text** for slides. - Ensure **keyboard navigation** in online slides. - Use high-contrast themes. - Provide captions in multiple languages. --- ## 🌍 DEIB Assessment: - Inclusive tone, neutral language. - No cultural/global diversity in examples; add perspectives from non-Western runtimes. - Neurodiverse supp - Document Tags: [[javascript]] [[openjs]] [[tc39]] - Summary: The speaker discusses various developments in the node.js community, particularly regarding module management and collaboration with the TC39 process. The speaker covers several proposals for improving module handling, including import attributes, import reflection, module expressions, and deferred evaluation, as well as highlights the importance of continued communication between the node.js project and the TC39 community. The speaker also mentions a proposal for streamlining asset handling. - URL: https://www.youtube.com/watch?v=1Gtzx7_IN4w&list=PLyspMSh4XhLO15jJD9Sj069fN18j12AbQ&index=9&ab_channel=OpenJSFoundation the point of this talk is that we've gota whole bunch of stuff happening fornode.js at the moment there's a wholebunch of module stuff going on at tc39and uh all of this stuff is going toaffect node so all of this stuff isgoing to be affecting node.js and weknow from the history of how the wholelesson process went that uh it'sprobably a good idea for the node.jsproject to collaborate and keep involvedin the tc39 process and not ignore it uh so as a member of the opengs fund we'renot a member of it as a representativeof the european.js foundation at tc39 uhthis is uh me presenting some of thestuff that's going on and uh effectivelywhen I'm at cc39 I'm representing thenode.js project so uh the point is thatthere should be a communication and afeedback loop uh from node.js uh andthis is a very strong feedback loopwe've got going here but hey I'm trying uh and uh between the project and what'sgoing on at tc39 and uh yeah uh so thisis going to go through some of thatstuff and I was then also going tospecifically call out John uh because uhthis morning he stated that uh jspm uhhas uh shouldn't be used on its lastrelease six years ago and there wasactually a release recently and uh thatthe project is still very much alivethere is more than one user and uh andit's not just me and uh it's it's actually a very interesting uh it has avery interesting approach to import Mapspackage management now so if you'reinterested in that topic the Project'sworked out a lot of those problemsum and I wish it was just less usersbecause then I wouldn't have the serverbill that I do every monthum so yeah back to the module stuffthere's a whole bunch of things going onuh and it's difficult to get a picturethis is from one of the slides that isbeing presented at the next tc39 meeting next weekand uh there there's a lot a lot ofConcepts going on and so are just goingto like blast through it and just showthat it's all pretty straightforwardstuff and uh node.js needs to payattention uh so the first One Importattributes just moved forward we've gotimport attributes but we use the S certkeyword instead of the with keyword thewith keyword just got passed it's nowpart of the cache key in the modulerecordso when you importing Json this is howyou import Json with es modules nowwe're going to still be supporting with and assert so we're going to supportbothin node.js and that's because that'swhat V8 will do uh and that was this isone of the things where uh we actuallybrought it up at tc39 that node.js oncecompat for a syrup because we're alreadyshipping that experimentally so it's anexample of a place where like no JS cansay here's a feature that we want and uhwe can be part of the argument formaintaining that feature so we're goingto have both with orisota will be usingboth keys for a while and you'll be able to then transition entirely to width umso that's it andyes exactly yeah and it's it's part ofthe registry key now so these keys arethe the level of uniqueness of modulesyeahuh import reflection this is theproposal that we're trying to transitionto stage three at the next meeting anduh in this proposal you can import amodule and you can get back a sourcereflection for that module So currentlyall modules in the module system are instance modules that means they haveone execution the execute once they'refully uh singular uh Source inputs arethe ability to multiply instantiate amodule so you get a source for it andthen you can create lots of versionsthat's also it's virtualization importreflection initially will ship it forwise and modules but then there will befuture proposals which will be able todo it for JavaScript as well uh so ifyou do whoever somebody you'll get awebsite module and what this does is itbrings sargo back uh tooling friendly uh Imports so that your your bundlick andeasily bundle this uh your securitytools can figure out that you're loadingwise and it's it's sort of baked intothe into the runtime properlyuh compartments can then take this andextend the same principle for JavaScriptmodules so you'll be able to instantiateJavaScript modules and probably evenhave a Constructor you can pass a sourcetext string this will actually be a newGlobal so it'll be the module SourceGlobal in JavaScript and that'll be thenext proposal that we're working on at some point and it'll effectively be areplacement for vm.source text modulewhich has its own issues but it'll be asimilar kind of modelbut fully baked into the Lang thelanguage and then yeahthat is a thing as well yeahright so there was a tc39 a distinctionbetween compartments and Realms that wasmade where the specs were split apart and Shadow Realms was Globalcustomization whereas compartments waspurely uh module level isolation and sothere's some separate things that theglobal separation was separated from themodule virtualizationI think that you can do with this youwon't necessarily have the global sothis is like that's a very good pointit's like well hey uh we want to be able to customize the global and we don'twant to just use the same Global when wedo this because our test infrastructurebut then you end up having to combineShadow Realms and compartments and sothese are the kind of workflows that weneed to kind of figure out and and uhuh yeah uh so uh well a compartment willaccess what you linked with servercompartment isn't actuallyself-contained in that sense Shadowrealm is the thing that's self-containedwe the boundary is fully serialized yeah um yeah I'll try and go through theserelatively quickly so we can uh I knoweveryone's tired but these are very goodquestions and uh it's exactly the sortof questions and and use cases that weneed to be running through with theproject uh so yeahmodule expressionsmodule Expressions will give you theability to Define modules inline soyou're able to Define sort of an inlinemodule and this will be fully static so it's not like an eval ejection of astring but inside of that module it's afull module scope and then you canimport that module and use it like anyother moduleand one of the nice things and one ofthe main things that's being built foris for workers so you can create aworker and you can then post the moduleinto the worker and you get a very niceworker experience but that still needsto be fetched out a bit at the momentit's just kind of oh you kind of post itto the worker and then somehow you'llpick it up on the other side and do something with it it would still need tobe imported just like it was importedhere in the worker once it's transferredum but there is there are proposalsthings like blank workers where youcreate a new worker without anyConstructor arguments and then be ableto initialize it with this module thatyou post somehow no one's working onthose interfaces at the moment that'sthat's a big area that we need to figureout because it directly affects howyou're going to handle uh multi-threadedapps in future so someone should work onit and then we'll get moduledeclarations so module declarations are able to actually name the moduleExpressions so these module Expressionswhere it's let mod equal module you canhave a declaration form and thisactually gives you first class bundlingbecause now instead of importing astring you can actually import theidentifier that corresponds to thatdeclaration the Declarations from thereand uh like custom scope like it's asort of a scope that exists outside ofthe the normal electrical environmentand you'll be able to link modulesagainst each other that way so like forexample you can have two modules in thesame Javascript file link them together in that Javascript file and run theexecution of that module graph in thesame module file so you effectively havea native bundling format for JavaScriptand that seems to be progressingand then deferred evaluation so this isumsomething that we had for uh common JSfor a very long while and we all knowthis is a great optimization to write anapplication you want toum uh optimize your execution path yourtop level executionso you put your require inside thefunction that's going to need it so it isn't it doesn't contribute to the startof time of the applications so you haveall the requires that normally runoutside if you put them inside thefunctions where they used you get lazyloading you save a whole bunch of filesystem access you save a whole bunch ofexecution and and loader logic we don'thave this for ES modules so the theproposal for deferred module evaluationis we have a special defer import andit'll be this this weird syntax to firststar asuh you'll get back a module namespacelike a normal namespace but this will bea lazy namespace so that namespace will be a an object of Getters and as soon asyou access one of those bindings it'lldo that lazy initialization process thatand and the exit the top level executionit will have already done the filesystem loading and all the rest so youdon't cut out the whole graph but youcut out the top level evaluation partsso you need to save execution time oncestartupand but at the same time it's fully partof the static module system so you kindof get the feature while not becomingtoo dynamic and then the assets proposal as the last one so we're only there uhit's does this whole pattern today whichis kind of a bit of a mess uh and youknow it's difficult for bundlers tounderstand these kind of code patternsuh people use very node.js specificpatterns they use very browser-specificpatterns andso you can't just expect everyone toknow to just use like new URL relativepath comma import metadata URL is theonly construct because it's quite acomplicated thing to write so this isactually a proposal created a long time ago by Sebastian Markovichum and you know he he kind of justposted and then moved on but we've kindof been able to reframe it within thecontext of all these new modelsproposals where it actually representsjust like another thing where these areall phases of the loader pipeline sodeferred module evaluation is like justbefore execution Source modules arebefore you instantiate asset actuallybecomes the earliest part of the um ofthe phase so it's actually likeum in in a weird way like become likethe most fundamental phase of theresolution algorithm but you can kind of get some asset which represents the keyof that module and then you can dosomething with that key and you can passit to any function that understands aresource key so you can treat that thingas like an assetum yeahyeah so this this is the proposal that'sthe least worked out and and no one'sactively working on it but it's it seemslike it's generally on the roadmap atthis point as wellum so uh an interesting one and I it'sstill unclear how it kind of integrates with a lot of other specifications youknow JS went through a person's puttingURL into a lot of things so it wouldtake URLs instead of pause URL objects Iexpect we do a similar thing with thiswhether it's repeat shoot is like anopaque resource that where you would putyour url or your path you can just saythis is a resource thing and it'ssomehow then like does it have a two URLon it do you expose that or is thatencapsody I don't knowum no ideayeah and you know someone wants to dothat Germany and stuff and then they're messing around Pages trying to work outthe patternyeahright well you have to do it in just theright way for it to work on the web uhwith with import.metid Arturoum so yeah there's lots left to do butthese things are kind of coming togetherand they're sort of sort of starting toform a roadmap of how modules are goingto progress and so some of the problemsthat we we didn't solve uh to begin withum but there must be continuedengagement between node.js and cc39 and if anyone's ever interested in thesetopics has feedback on these topicsum you knowit's if there's going to be a continuedengagement process and we mustn't end upin a situation which we are not likecreating solutions for node we're justcreating promise for it we need to makesure that the stuff is working fornode.js interests and so that's it anyquestions happy to answer themyes right in in some kind of abstract computerprogramming sense if I knew anythingabout theoretical programming I'dprobably throw terms like you knowabstract terms around but like in asense a module and a function you knowhave similarities yeahknow that these are neverkeep your code isokay right so this is not a um a new function you pass a string toand you can pass arbitrary Source textand because globals typically have ahigh level uh privileged capabilities inJavaScript and the web platform that's asecurity violation and and so uh in thiscase you know how does the same thingnot apply to module where I'm passing JSmodule well JS module is not a string JSmodule is a an actual module Sourceobject which like is is more like the result of new function it's the functionthat hasn't been called yet so having ahandle to a function is our K new moduleinstance is more like calling thefunction in in the module analogright right because the module system canbecome a secure capability system infutureand in browsers we have CSP you can saywhich domains are allowed to providemodules that's where it works todayand perhaps we will get sort of moreconstrained modular security modules in futuremodels but uh at the very leasta security analysis tool you can put itonto the application it can tell whatthings are going to resolve to know whatthose sources are statically and so youcan do a static verification of yourapplication because you know everythingthat's being loaded whereas if you havearbitrary strings the sources of thosestrings can escape analysis and then youhave a security issue issue and so thatthat's the whole injection Vector problem so by by relying on the themodular system you get that and not onlythat but you also get like some nicefeatures that you get like a nice Syntaxfor like mocking your tests or somethingright and and mocking you you can loadyour test module that way and then runit multiple times with different uh youknow or your your fixture and you canrun at different times there's differentenvironments or something like that soyou get this multi multi-instantiationwhich in a sense you know the Marchsystems are constrained in having singular instantiation already so itopens that door in a way that uhintegrates in a first-class way with themerge list okayum I have actually two tiny questionsfirst one which one of those are alreadyin stage threeso we're actually going to put we'reaiming for stage three on the so thisone just went through recently uh sothat's already now stage threeuh info reflection next week at cc39we're going to aim for stage three onthis one and then it would beimplementation readyuh if we don't get stage three at this next meeting we should be able to get itin the July meetinguh and then this one is a far way outmodule expressionsare coming down the pipeline and thesethings are sort of maybe more three tosix months 12 months yeah still cool butum besides the assets one is itconfident the current uh specificationlike or do you think that there will beany major changesthen everything's up in the air and yeah yeah it goes through committee yeah yesum finally you know we're talking aboutfor example node.js and tc39collaboration should be very tight whichwhich I agree but what about winter CGwhich is something that everybody istalking about right yeah but it's also away whole you know different runtimesthat have very different ideasto try to tackle also this things andwork together do you think it will bebetter if for example tc39 got things toget done in node through that what that doesn't make senseumso yeah these things all affect winterCG so far as you know winter CG is alsobased on aquascriptum I thinkuhso far as winter CG is is still less ofa platform effortum and while node.js remains a dominantplatform yeah we can we should think about how these things perfect our usersyeah but for example the modular stufflike you mentioned yourself it feelslike thisimmense amount of work no Jazz how doyou think it well yeah so all of thesefeatures will like they would be V8features so they would just sort ofarrive and then it would be up to us tokind of implement themand the point is that uh we should makesure thatthey're going to work for our users and umuh for the for the most part I think uhyou know I've been really happy with theway that the process has gone and we'vebeen able to work through a lot ofdifficult thingsumbut at the same timethat there there needs to be some kindof review from the users yeah and and weneed to make sure that's taking placeum so yeah and when you mean review from the usersis also once for your lender'sexperimental for people to actually getpaid that's too late right that's toolate yeahwhen then no yeah it's uh you know Ithink this the the next few months andthe you know the next year or so a lotof these things will be fleshed out andso if if people are interested in themor if they have any thoughts on it Now'sthe Time toand um yeahuh yeah this module declarations one Imean I we don't even know if it'll gothrough but I think you know the reallyinteresting is like the source which ismoving and then module Expressions isvery interesting from like a workerperspective that you can always you'realways writing likeyou're getting close to being able towrite a block of code and just sort ofshipping it off yeah this is really coolbecause I don't need a bundle or anymore or something that what defines the model it still needs a bunch of figuringout um but yeah that's itUrbanso the import with the type Jsonis that plan to be extendable I foreseea future will people where people say ohwell you're giving me the option to saywhat type it is let me Define othertypes that it should be does that make sense right yeahhas that been considered that the theseries or the second of this isintroduced and more people are aware ofit they're going to be like well whycan't I put type typescript right or orthis is excellent feedback butunfortunately this is a stage three specso you're too late to provide feedbackon it and you should have been involveda year agoyeahI I haven't been involved in thisdiscussion too much myself either but it's it's a done deal nowall right thank you everyone and uhplease I'm always happy to discuss thesethings sir uh thanks thanks for all yourinterests, New TC39 Modules Proposals, OpenJS Foundation, 01h3j5zk7zpend57ase2v0ydfk.