FINALLY. I don;t know how long we could have come with this still being a thing you need a module for, or you have to code yourself.
Hopefully we get `fs.mkdirp` and `fs.remrf` somewhere down the line.
> Add support for ESM. This is currently behind the `--experimental-modules` flag and requires the `.mjs` extension.
I don't like the `.mjs` extension, but I understand the need for it, and I'm just glad that modules are finally here.
Dependency edges out of module land should be explicit, because those aren't going to work on the web, and the web matters more than node.
They should have left requiring for CJS modules and let things be crappy for a while as requires and CJS are phased out. Eventually only ESM would remain except for in some abandoned packages, which could still be required.
But now CJS is going to live forever because it's the default and ESM is opt in.
There are trade offs to be sure, but I prefer the languages (and in this case platforms) that have batteries included.
Yes, this means that if your project depends on ten other projects, and all ten projects implement their own copy-file routine, your project will end up with ten copy-file routines.
When working on a project and you need to copy something for the first time, you shouldn't have to do:
* Ok I need to copy... What npm package does that again?
* search NPM for copy
* figure out which package is "best"
* npm i some-copy-package
* do thing
Streams are too slow you say?
I've never had a problem with no explicit copy, but I am very happy it has been added...
In macOS libc there's a copyfile(3) function: https://developer.apple.com/legacy/library/documentation/Dar...
I read that a lot. Why do people don't like the new extensions?
Seems like the most elegant and programmatically more performant and less hassle free, solution to the issue.
Everything else looks like a terrible kludge.
Changing from js to ts is an inconvenience sufficiently big enough to adopt flowtype instead.
Probably because you'll end up with .mts, .mjsx, .mts, .mtsx.
Or mpeg transport stream:
I've chanced upon the "same extension for the same thing" as a problem maybe 2-3 times in 30+ years.
.mts is unheard of.
There's gotta be a very good reason to bog down the core with more stuff, since that equals less other stuff and more bugs. Some of the few valid reasons are ubiquity (which HTTP is, but Windows and sending files are not), or things that were impossible before (like no overhead file copy).
Because copying a file fits right in any kind of "small core" -- and helps create a more dependable and usable "rich userspace" which doesn't need to reinvent the wheel 200 times for basic stuff.
Node has been a frustrating language to switch to from C# from the perspective of stack traces. It seems in node they devolve into relative meaninglessness beyond the first line or two. I have fond memories of juicy stack traces like homing beacons.
I'm secretly hoping somebody will jump in to tell me I'm just reading them wrong or something...
The open source landscape is filled with forks of projects that diverged for a variety of reasons.
A fork means the people involved are still contributing code and it can potentially be merged upstream.
The alternative is they don't fork, and contribute nothing because they're unhappy with the original project.
Just some ranting person(s) taking their marbles and going home. Let's hope the door didn't hit them on their way out.
Otherwise, Node looks totally non-impacted and business as usual.
You mean four out of the 13 CTC members leave to make a fork and the project is "totally non-impacted"?
This is from the Ayo "GitHub":
"For the time being, simply by mirroring them to preserve drop-in-ability. Eventually, I have no interest in retaining compatibility with Node Core at all, because that would involve participating in and interacting with a community with deeply dysfunctional governance."
Yeah, good luck with that.
In most cultural matters, this community tilts quite progressive. However, "Codes of Conduct" are an exception case, in which the community's libertarian streak clearly dominates. I do not believe that the moderators approve of that deviation. It would not surprise me if this entire thread were likewise flagged and removed if this subject draws too much conversation.
That's it? I'm happy. The toxic SJWs are out. Sounds good for the project as a whole.
> On Tuesday, the thirteen-member steering committee came together to vote on whether to remove Rod Vagg, a TSC member and Node.js contributor, over his controversial statements on Twitter and GitHub that prompted complaints. They also voted on whether to ask Vagg to resign.
Laravel borrows a lot from Ruby on Rails, so maybe that might be more your cup of tea. A lot of Rails developers are trying Elixir & Phoenix which is an awesome functional programming setup. PHP has also been trying to become more like C# it seems. So maybe .Net Core & C# are worth a try? If you go the C# route, I suggest using Visual Studio (the full IDE) as I find most of my joy typing C# comes from the IDE. Whereas a language like Elixir the joy is the language itself.
Moving back to the linked story, are there any long running issues with Node that are still not yet addressed? Are nearly all common issues resolved?
All common issues are quickly resolved, almost by definition, in a long-running successful project like node. Lots of people depend on that being the case.
It's just not always resolved in core (which is why npm/yarn/webpack and a hundred other awesome derived works exist).
Not sure about Node, but regarding other "long running successful projects" you'd be surprised.