16 ms·
NPM and NodeJS should do more to make ES Modules easy to use
- deleted 2y ago[deleted]
- righthand 2y agoWhy does it matter that people use ES modules instead of requires? They’re compatible enough. Javascript is weird because it has this directive for browsers to keep compatibility, but then has proponents for language changes that people try to force on everyone through framework/library use and design. All to the benefit of someone reading code the way they want to read code. It hasn’t changed because it’s not a real problem. This is like forcing main as the default branch in git.
- rty32 2y agoWell, to begin with, they are NOT compatible, in the general sense. What you perceive to be compatible works because of tons of (often dirty and ugly) hacks people put together, with many issues. (Hint: top-level await). Do your research.
- righthand 2y agoHence the “enough” modifier. NodeJS isnt a browser framework, do your research.
- tqwhite 2y agoI could not agree more. In fact, the introduction of ESM has been entirely pernicious, causing more problems, not fewer. Why? Because there is no importSync(). If that existed, it would be easy to interoperate.
- deleted 2y ago[deleted]
- tracker1 2y agoI think it would have been more prudent if Node had chosen to stay closer to Babel compatibility in terms of how it handled ESM + Require. I know there were reasons to break things... but it could have been smoother.
- spartanatreyu 2y agoWhy do you want an `importSync()`? You could achieve the same thing with a bunch of `import()` calls, but I'm not sure why you'd want to when you can just use the `import` keyword instead.
- tqwhite 2y agoI have a ton of projects and a huge amount of utilities and such, that all use CJS. You cannot just use 'import' if you also use CJS. To use 'import', it must be an ESM module and the you cannot use require() to access CJS utilities. In CJS code, one can use import() to bring in ESM modules but, import() is asynchronous. The problem is that I have a lot of code that is not asynchronous. To add an asynchronous function requires substantial rewriting that I am rarely willing to do. If, in addition to the asynchronous import(), there was a synchronous importSync(), I could use ESM modules any time I want. That would allow me to... 1) Use and support new utilities that are ESM. 2) Write new utilities that are ESM. Presently, I always target CJS because that's what I have to use. I have read that there is a new version of NodeJS that supports using require() for ESM modules. That will be a huge, huge, huge improvement although I would prefer importSync() so that it was clear when I was using an ESM module. Even so, I will take it.
- lenerdenator 2y agoSurely, this will be the thing tacked onto JavaScript that will make it easy to scale and reduce toolchain complexity......
- fwlr 2y agoBun put a lot of work into making both “import” and “require” always work regardless of whether it’s given a commonjs or an ESM target. I’d say that’s half of the right idea: make only import work with anything. Another angle that might be effective: take the most popular aspect of commonjs - `require(‘extensionless-string’)` - and tie it to the least popular aspect, .cjs extensions.
- postepowanieadm 2y agoBut why do you want to break half of a working solution?
- tracker1 2y agoIt's closer to how Babel worked out of the box for half a decade before Node added their implementation. It's Node that broke a half-working solution.
- fwlr 2y agoIn fairness - given a choice and some time to think, I would probably not choose to actively break commonjs. However, if I was tasked with increasing ESM adoption, I would go about it like this.
- montroser 2y agoNode should just do like bun and support intermixing both. It was a mistake to force this schism -- untold hours of frustration and busywork for maintainers and developers with no hope of actually "completing" a mythical full transition to the new world. And for what? In Node specifically, it's not as if esm actually solves any real problem! In the greater ecosystem, sure it has some benefits, but Node doesn't even have to choose. Just support both at once, like bun and build systems have for a while, and let's move on from this nonsense.
- Me1000 2y ago“Just” is doing a lot of heavy lifting here. It’s so frustrating watching people think it’s just because a bunch of smart and hard working people are either lazy or stubborn.
- mardifoufs 2y agoI'm completely clueless w.r.t js modules, but I'm wondering how did Bun manage to do it? Does it work well?
- vlakreeh 2y agoIt works great for 90% of use cases, but getting that last 10% to work is really really hard so Bun (and node 22 which supports the same thing with an experimental) just throws an error in those cases. The most notable thing is `require`-ing an async ESM module from CJS, because require is a synchronous call you cant just async-ify it trivially.
- preya2k 2y agoAnd then here is one of the biggest backend JS frameworks (NestJS) clinging to CJS/holding off on migrating to ES modules. https://github.com/nestjs/nest/issues/13319 https://github.com/nestjs/nest/issues/13319
- tqwhite 2y agoAnd, if you read that issue, you will see that they are not because the only real benefit is spiritual, 'more consistent with the future'. Give them an importSync() and the migration can happen incrementally.
- ulrischa 2y agoThe whole node npm ecosystemand tooling is so bad and broken. No other language is so frustrating. JavaScript was bad in the early years took a good way but is now stuck again. I tried webcomponents with lit. All very easy in the beginning. But when you try to use an external stylesheet you hit the wall of the modern js world: css can not be imported in js without a massive tool stack. I whish tue main focus would be tool- and buildless. This is really what is lacking
- cxr 2y ago> The whole node npm ecosystemand tooling is so bad and broken. No other language is so frustrating. Neither Node nor NPM are languages. > when you try to use an external stylesheet you hit the wall of the modern js world: css can not be imported in js without Uh...?
- tqwhite 2y ago[flagged]
- efilife 2y agoYour comment got grayed out because you dared to have a different opinion than the hivemind
- tqwhite 2y agoThere are a lot of arrogant people in Javascript-land. If you look at the number of imperious attitudes in this thread ("you misunderstand what a module is"!!), it's very bad. But it's also endemic of the attitude that got us here. ECMA has done a bunch of things that are all swell for fancy people which ignore the main Javascript virtue: It is (used to be) comprehensible to the average Joe. Don't get me started on the scope problem of trying to get values out of .then(), catch().
- efilife 2y agoYour comment now appears as [flagged]. Can't have an opinion. And hackernews was supposed to be a discussion forum for curious souls? 100% agree on the try/catch problem. Remember that you can just use async/await to mitigate this, way more convenient
- replete 2y agoCompletely disagree on getting rid of .mjs, .mts, .cjs, etc. This has actually solved a lot of the problems we had of mixed module loading IMO
- WorldMaker 2y agoIt's probably going to be a bandaid for a while longer, but the problem is "mixed module loading" and we should fix that problem rather than rely on bandaids long term. The last .cjs file I've needed for a while now in type="module" libraries has been for eslint config files and eslint finally supports ESM configs. Everything is just .js, as it should be. I agree with the article that type="module" should be the default and once it is the well established default the bandaid of .mjs, .cjs, et al extensions should probably provoke a deprecation warning rather than being another long-term tech debt part of Node.
- deleted 2y ago[deleted]
- jakubmazanec 2y agoI followed advice of Sindre Sorhus [1] and moved all my packages and apps to ESM year ago and couldn't be happier. Only Jest and ts-jest were problematic, so I replaced them with Vitest. I also never encountered problems because of the so-called dual-package hazard [2]; but IMO this isn't that much different than when you have two copies of React in node_modules - it's simply an npm/dependencies problem, not ESM problem. [1] https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3... [2] https://nodejs.org/api/packages.html#packages_dual_package_hazard https://nodejs.org/api/packages.html#packages_dual_package_h...
- simlevesque 2y agoPeople never wanna work or learn. It's not even that big a pill to swallow.
- drschwabe 2y agoRefactoring your entire codebase just to use that one ES module that is incompatible with CJS is a big pill to swallow if your codebase is ... big (or you have many).
- jakubmazanec 2y agoTrue, but if you just do it, even if it's a large undertaking, the benefits of ESM-only code are bigger than being able to use more packages. And someday you will have to move to ESM anyway.
- pictur 2y agoThe last sentence is a good way of consoling yourself. I hope no one takes his advice seriously and implements it. Good luck with your own nonsense.
- drschwabe 2y agoOn the flip side we have other amazing devs who are also active with cutting edge libraries and simply do the small amount of extra work to make their modules available in both ESM and CommonJS to this day: https://github.com/WebReflection/uhtml https://github.com/WebReflection/uhtml
- plopz 2y agonot being able to mock es modules in tests is a real pain
- o11c 2y agoAs someone who only dabbles in JS, one problem is that ESM makes polyfills impossible. And polyfills are mandatory in the JS ecosystem. It's quite meaningful for dependencies to be fetched asynchronously, but sometimes you really need something to be executed in the order it's written.
- norman784 2y agoI would argue that polyfills are not needed anymore, you are safe using ES2022 or even ES2023.
- tracker1 2y agoMostly agree with the above, outside some ES3-ish scripting environments (Adobe and others), polyfills for a lot of functionality isn't needed strictly for JS support. And even then, can still be part of bundling or shimmed outside your application script(s). And if you're bundling, then you can add them into the process. I've been avoiding most things that could require a polyfill since 2018 or so anyway as green browsers are pretty feature complete. As much as I'd like the F# style pipelines, and there are a couple other niceties, I don't miss much.
- Sephr 2y agoPolyfills are often necessary because new features are still added to the standard library, and runtimes all have varying levels of support for new features.
- dbalatero 2y agoFalse, I just added one the other day for the scheduler API.
- TheRealPomax 2y agoAt the very least, they finally should switch over to ESM-by-default and announce that 2 or 3 major versions in advance. "From Node 25 all code is assumed ESM unless you have `"type": "commonjs"` in your package.json" is not a particularly difficult message to send out and would stop people from writing new projects using the now legacy CJS (super great that it existed back when JS had nothing even close to a dependency model, but it should have been retired once ESM went from stage 4 to "this is literally and officially how JavaScript works")
- pictur 2y agoif you look at most npm packages, you can see that versions that do not support es modules are downloaded more. and it's been like this for years. an example package: https://www.npmjs.com/package/p-queue?activeTab=versions https://www.npmjs.com/package/p-queue?activeTab=versions
- h1fra 2y agoThe fact that `npm init` still not default to `type: module` is baffling
- meego 2y agoBarely a third of "high-impact" packages on npm are ESM. And that's with a generous definition of what an ESM package is. [1] [1]: https://github.com/wooorm/npm-esm-vs-cjs https://github.com/wooorm/npm-esm-vs-cjs
- 999900000999 2y agoI'm tempted to say we need a complete reset of the NodeJS ecosystem. It will never happen because it would require coordination and money, but instead of having millions upon millions of different NPM packages, many of which are downright harmful, we should have a careful selection of maybe the top 20,000 or so. And then maybe call the next generation of node something else, maybe ProJS.
- paulddraper 2y agoIsn't the problem that ESM is proving almost too much of a reset? I'm not sure I understand what you're going for.
- PaulHoule 2y agoThis is timely to me because I am in the middle of modernizing a project that was ejected from CRA years ago and now won’t build in Node 18. I’ve worked on a few big React projects but haven’t really looked much into how the build works, I found out upgrading one thing forced me to upgrade other things and I wound up making a lot of changes by hand to the build scripts and figured I’d probably screw something up. Dependencies changing from CommonJS to ESM was probably the most common problem that can frequently solved by version bumps (at risks of adopting changes you don’t want) At some point I decided to try the alternate path of switching to Vite for a build system since I’ve had good luck working with it for some VR side projects. It’s funny how you can code on front-end Javascript and not need to learn about CommonJS until something like this hits.
- apitman 2y agoMy only complaint about the current state of ESM is that I can't figure out how to resolve the following: 1. I'm developing a library that depends on d3js 2. I want the library to be usable without any build tools. Just clone my repo and host the files from a static server. Or just import directly from jsdelivr 3. I also want people to be able to use NPM to install my library if they so choose The problem is if I vendor d3js, then developers who consume my library via NPM might end up with 2 copies of d3js in their app, if their app also uses d3 directly. But if I don't vendor it, then my ESM-only users have to use an import map to resolve the bare specifier in the browser, which is kind of ugly and confusing. More details: https://stackoverflow.com/q/78645299/943814 https://stackoverflow.com/q/78645299/943814
- noiv 2y agoThat's when I started vite first time. I think it's the build tool closest to no build tool.
- tobyhinloopen 2y agoIt’s such a waste of time to have this change so often. Can we just stop changing things? Require and module.exports was fine.
- 123yawaworht456 2y agoold thing bad new thing good
- tobyhinloopen 2y agoI don’t care if it’s good or bad, I just want it to work, and have it still work 10 years from now
- zazaulola 2y agoJesus, what the hell?! Why do you dislike `require()` so much? Just imagine a person who doesn't write modules in Node.JS, but he would like his small scripts to be placed in one JS-file - without any additional directories and `package.json`. His script, for example, updates data for a desktop widget, is easily bypassed by standard nodejs modules and he has hundreds of such scripts in his folder. Why does he need all this `import` overhead?
- byt3h3ad 2y agototally unrelated, but for the first time did i see a discuss here to threads. i had to double check if it was really the threads by instagram.
- deleted 2y ago[deleted]
- ramesh31 2y ago>NodeJS can officially drop support for require and module.exports in a future version, creating a bit more pressure to migrate. This will never, ever happen. Too much of the foundational ecosystem relies on it.
- tqwhite 2y agoAn insanely bad idea.
- game_the0ry 2y ago> This will never, ever happen. I hope for the sake of the nodjs ecosystem, you are wrong. Fragmentation issues are one of the many reasons that nodejs struggle with adoption.
- bastawhiz 2y agoIf it does happen, it'll only cause more fragmentation. Because lots of projects and libraries simply won't upgrade. Look at Python: it took them decades to get folks to upgrade to py3k because they broke the old code. Do it to Node and it'll be decades of fragmentation.
- dgb23 2y agoBreaking code that doesn’t need to be broken is the biggest redflag for a platform or foundational library.
- baq 2y ago> nodejs struggle with adoption Woah there. If nodejs is struggling for adoption I don’t know what isn’t.
- game_the0ry 2y agoLet e put it differently: nodejs would have more adoption if it had less perceived instability.
- jeswin 2y ago
- Aeolun 2y agoOr you can use Bun and have it handle all the nonsense. Or esbuild, but then you get a big blob, which isn’t really usable for a lot of things. The extensions were always silly to me. Who changes only a few files to esmodules? You either change your whole project or not at all.
- lefrenchy 2y agoDoes it actually handle it though? I use bun to run my remix app at work and I have run into ESM/CJS issues.
- dimgl 2y agoBun handles all of the nonsense but the catch is that it blows up both in dev and in production. Wake me up when Bun doesn't segfault/fail to work at all.
- jasfi 2y agoI look forward to the day when Bun can run Next.js. Apparently the main showstopper is in the Next.js router.
- evilduck 2y agoI'm not steeped in the history of this issue but I periodically run a maintained and up to date NextJS app via Bun in a dev env just to monitor performance and compatibility. It uses the app router and the edge runtime middleware, hosted from a Docker container. I haven't seen massive benefits using Bun since Next doesn't use the Bun-specific libraries that make their performance numbers great, but I haven't seen any game breaking issues either, it runs and all the app's E2Es pass.
- afavour 2y ago> Who changes only a few files to esmodules? You either change your whole project or not at all. Transition. It’s a much lighter lift to transform a project piece by piece than do the whole thing.
- knallfrosch 2y agoI don't know which is which. I don't care. I don't understand the benefit of a top-level await if I can simply await in a different file. I use Typescript which adds a layer in-between anyway. At work, we use Angular, which (I think) uses both Typescript and maybe esbuild. Or Webpack. Does it compile to ESM, or CJS? Who knows, and it will change in 2 years again anyway. All of that is something that I consider to be platform-level. It's insane that millions of feature-writing devs are expected to know all these arcana. Then again, it might be fixed™ soon Ⓡ https://joyeecheung.github.io/blog/2024/03/18/require-esm-in-node-js/ https://joyeecheung.github.io/blog/2024/03/18/require-esm-in...
- dboreham 2y agoNow we see the benefit of having adults in charge, e.g. as is the case with golang for example.
- throwitaway1123 2y agoGo has the benefit of not having to reach a distributed consensus amongst a variety of individual browser vendors. Try compiling a large Go project with tinygo to get a glimpse of what it's like to have to deal with multiple independent runtimes [1]. If the browser vendors had been able to ship ES4 or ES5 with module support between 1999 and 2009, then Node probably would have implemented it from the very beginning, and there would be no dichotomy between CJS and ESM. [1] https://github.com/evanw/esbuild/issues/1111 https://github.com/evanw/esbuild/issues/1111
- dimgl 2y agoThe whole point of this is that ESM was very poorly handled. It's irrelevant to TypeScript, esbuild, Webpack, etc. That tooling handles the complexity for you and sometimes that backfires. I've run into a lot of headaches with the TypeScript compiler. The fact that you don't know whether your codebase uses TypeScript, esbuild or Webpack is disappointing. It means that those worries have been handled for you and you don't care to learn them, which is never a good stance if you work with this on a daily basis. But I somewhat agree that it should all be vastly simpler. I also kind of agree with the downvoted/flagged comment re: Golang. The way the JavaScript ecosystem works is highly dependent on the way Node is handled. And Node has, for many years, made ESM needlessly complicated.
- rezokun 2y agoOr JS ecosystem should drop ES modules since they have only brought pain and unnecessary complexity without real benefits for years.
- pavlov 2y agoES modules work natively in browsers, which are the slow-moving ships of the ecosystem. Changing course for them is completely unrealistic. There’s a billion browser clients out there. That ensures that whatever API they ship, an increasing amount of code will be written directly against it. Everybody else just needs to adapt or be seen as incompatible with the baseline of JavaScript.
- rezokun 2y agoShow me a real product on the web that does not compile or bundle and uses native modules for code delivery. It's a dead technology that only fragments the ecosystem and makes life harder.
- jsmith99 2y agoMany bundlers output module format - it makes features like code splitting (chunking into separate files) convenient.
- rezokun 2y agoES modules mean you don't need to bundle your code; you just include your index.js in HTML, and all 30,000 JS files of your project come to the user's browser without trouble or delay (let's wish them luck, lol). Since you're bundling, it doesn't matter which module type you use; CJS has worked with code splitting perfectly for over 10 years. However, it's a pain every time you try to import a CJS library in your ESM or vice versa. The truth is, you can't just drop all legacy CJS packages in most real-world projects.
- pavlov 2y ago
- mirekrusin 2y agoAnd yet approximately 100% of js/ts devs are using ES module syntax and don’t write blog posts about it. Magic.
- tqwhite 2y agoAccording to the article, three quarters of the npm projects do not use ESM. Their programmers must be very magical.
- mirekrusin 2y agoYes, magic of transpilers (typescript, esbuild, swc, babel etc).
- catapart 2y agoJust use JSR[0] and only deal with npm when a project forces you to do things backwards. Since JSR packages are available on npm, there's nothing lost. [0]https://jsr.io/ https://jsr.io/
- jmondi 2y agoI have mixed feelings about the JSR requirement for explicit typing. Other than that, it is pretty great!
- catapart 2y agoHm? This is news to me. As far as I know, you can just publish pure javascript. I know that it's going to give you a worse 'score' if you don't have types, and it may require explicit typing of TS (but, strictly, so does TS), but I wasn't aware that there was not any way to publish to JSR without types. I'll have to look in to that, thanks!
- FractalHQ 2y agoThis is the best feature imo. Never again will my time be drained by someone else’s failure to type their spaghetti.
- nox101 2y agojsr seems great! I hope they work out their kinks but I'm really glad someone is trying to push things forward.
- creesch 2y agoNeat to get to know JSR, but doesn't this have very little to do with the contents of the article you responding to? While I know NPM is in the title, the actually article is about module imports which JSR doesn't change.
- catapart 2y agoThe article is saying "this ecosystem should change because it doesn't do specific things that make sense for it to do". JSR says "here's a way to leave the original ecosystem alone, but have a better-fitting ecosystem that does the things you want". (not sure about the 'jsr doesn't change' bit? It literally requires ES modules, in lieu of common js modules). Seems pretty relevant, to me, but YMMV. I understand it's not a direct answer, but it seems as relevant as "here's typescript" to someone saying "we should add types to javascript".
- can3p 2y agoI think the module imports apis are a python2/3 moment for node.js ecosystem. There is no clearly superior way and as a consequence not too many people care, however it hurts for real. The proposal to disable node.js style imports will just split ecosystem and make a large part of industry stick to ancient version / make a fork. Is that really worth the gain? Just check how long it took some bigger projects to migrate from python2 to python3
- deleted 2y ago[deleted]
- cxr 2y agoThe difference is the language/standard in question neither originated with NodeJS nor is NodeJS now nor has it ever been led by the people behind the language/standard (unlike Python)... When you hear "NodeJS", you really need to bethinking of it in the same category as IE (wrt browser behavior) or Visual C/C++. It's but one, often (knowingly/deliberately) quirky, non-standard implementation by a group that doesn't necessarily have your best interests at heart or the interests of those outside their own platform umbrella.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- pcloadletter_ 2y agoHow are the deer in Nara?
- bcherny 2y agoCute, when they aren't trying to eat my phone.
- gbuk2013 2y agoCan someone explain to me what the advantages of ESM actually are to me as a backend dev who uses import / export syntax in TS already? Parent article mentions static analysis and synchronous loading on startup but that has never been an issue for me despite building some large and complex Node apps over the years. I’ve looked into this in the past but all I could find are strong opinions without solid technical reasoning.
- Quothling 2y agoThere isn't that much difference on the backend if you use Node and Typescript. ESM is the standard for JavaScript and you'll probably run into situations where you can't use a new JavaScript feature with CommonJS as early as you can with ESM. There are disadvantages and advantages to how the modules load on Node, but ESM is generally improving faster than CommonJS. If you're looking into other runtimes ESM used to be the way to go because of Deno, but these days you're likely either running Node or Bun and both work well with CommonJS and ESM. If you do both frontend and backend work, or if your team has a lot of cross-over between the two sides of the ecosystem, then it'll likely be easier for you to use ESM on both ends as CommonJS isn't supported by browsers. I think the primary reason CommonJS is still around is mostly because Typescript replaces it's import/export module system with something that's basically similar in syntax to the way ESM does it untill it gets transpiled into Javascript. If people actually had to work with CommonJS modules in 2024 then I think they'd likely go insane. Not everyone will agree with me on this, but I don't think there is a reason to rewrite old projects into ESM unless you have a very good reason to do so. That being said, there isn't really a good reason to start new projects with CommonJS either... Unless you have a really good reason to do so.
- WorldMaker 2y agoA big technical reason especially specific to using Typescript: not transpiling to CJS speeds up your Typescript builds. It also opens up more options when Typescript is just "type stripped" rather than transpiled to an incompatible module syntax. You probably still want a full Typescript compile at CI time to get robust typechecking, and you'll have the Typescript LSP doing its thing in your IDE still, but you can use type-stripping tools like esbuild for very fast type stripping in some portions of your inner dev loop. The static analysis that ESM supports is handy because it opens up technical benefits like Tree Shaking. Your apps might run on SSDs, you probably don't have a lot of reasons to bundle them, you likely aren't worried about on disk size, you might not be worried about bundle publish size to npm, and so you might not think Tree Shaking applies to you, but V8 under the hood of Node is still going to do Tree Shaking of memory and garbage collection for you with ESM in ways that it simply cannot with CJS. I've seen some real memory performance gains in Node apps just switching from CJS to ESM already, and V8's ESM optimizations only seem to get better as more ESM is deployed in the wild. There are more, smaller technical benefits, but "type stripping not transpiling" and "in memory tree shaking" are strong ones that are easy to overlook.
- bastawhiz 2y agoThe simplest solution is to stop requiring the top level package to be a module. Allow es modules to be require()-ed. It's be synchronous and slow and ideologically impure, but it'll make it so that millions of projects (mostly private!) will be able to start adopting es modules without a massive refactor. Anyone with a project of significant age or size looks at ES modules now and thinks "fuck it". There's no return on investment to convert (other than less pain while trying to upgrade or adopt new libraries). It's a big undertaking with loads of risk (modifying import order isn't safe!) and the payoff is "it's the shiny new thing". I had been using adminjs at work. Their new major version was ESM-only, and it was easier to _write a new admin panel from scratch_ than it was to refactor our entire codebase to be ESM just so we could upgrade one library. I expect that's the situation at hundreds of thousands of other companies. Like for all the belly aching that happened over async functions (and the whole function color rant), synchronous and asynchronous functions work together just fine through plain old promises. You can easily use async functions alongside functions that use old fashioned callbacks. ESM vs CJS is a file coloring (versus function coloring) problem, but there's no interoperability. There's no escape hatch when you just need one file to use another file but their colors are incompatible.
- afavour 2y ago> it was easier to _write a new admin panel from scratch_ than it was to refactor our entire codebase to be ESM just so we could upgrade one library A middle ground answer would be using import() in CJS to asynchronously require the ESM module. It would require some hacking around your loading flow to ensure the module loads before you try to do anything with it but would still be preferable to rebuilding the entire thing.
- bastawhiz 2y agoI don't disagree! But is there really an argument (other than an ideological one) for why it needs to be an awaited import? Why does it matter that it's async?
- eyelidlessness 2y ago
- jeswin 2y agoES Modules are better in every way. But I do believe they got the syntax wrong - should have been "from fs import { readFile }" so that auto-complete works. Python got that right, but that's the only thing Python got right ;)
- ComputerGuru 2y agoI feel like it’s going to be an inevitable language update to allow that syntax. I’m surprised TypeScript hasn’t succumbed to the pressure to support that syntax, but they’re really strict about where they allow deviations from the JS superset.
- jeswin 2y ago> I’m surprised TypeScript hasn’t succumbed to the pressure to support that syntax They won't do this without consensus in TC39. They shouldn't either; that'd be worse than this niggle.
- ComputerGuru 2y agoWhether they should or not and whether that would be bad or not depends on how close of a relationship you believe should/does exist between TypeScript and JavaScript l, specifically in the TS to JS direction. If I said language foo that isn’t TS but transpiled to JS all the same was considering that syntax, people might have a different opinion.
- WorldMaker 2y agoSince Typescript 1.0 it has mostly taken the path of wanting to follow TC-39's standards rather than lead them. The most notable exception was an experimental flag for decorators at too early of a stage that's currently playing out in a compatibility war between the too many projects depending on the experimental flag in Production builds versus the actually standardized behavior. Between that and some remaining warts from <1.0 mistakes/incorrect assumptions, there's plenty of evidence that it is a good thing that other than its type system TS focuses on following standards rather than trying to lead them. There's a place for the language "foos" that want to lead and champion new standards. As an ecosystem we all seem to benefit from Typescript not being that language (anymore, mostly not since 1.0 with the few obvious mistakes aside). It's a part of what makes Typescript trustworthy as Production tooling. It's also what helps make Typescript mostly "cheap" and "unextraordinary" in Production build pipelines.