Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node v8.5.0

nodejs.org

Post reply on HN
Print view View original

51–57 of 57 posts

Re: Node v8.5.0

#51

Post by VeejayRampay »

tkone wrote: post #50
thom_nic wrote: post #40

Earlier quoted context omitted.

As Larry Wall said, "Easy things should be easy." 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 * require("some-copy-packge") * do thing The first 4 steps should be unnecessary.

or just fs.createReadStream('file.txt').pipe(fs.createWriteStream('new-file.txt')) Streams are too slow you say? fs.writeFileSync('new-file.txt', fs.readFileSync('file.txt')) I've never had a problem with no explicit copy, but I am very happy it has been added...

Are streams really considered "slow"? Would your second example be faster in practice for most files?

Re: Node v8.5.0

#53

Post by dchest »

Johnny_Brahms wrote: post #16
pitaj wrote: post #2

> add fs.copyFile and fs.copyFileSync which allows for more efficient copying of files. 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…

Wiuldnt implementing those be trivial? They are hardly going to be "too slow" like file copy might be, and with the JS love of small packages this should already be a solved problem.

I'm not sure how fs.copyFile is implemented, but file copying is not the same as reading the contents of file and then writing it into another file, which is easy to implement. There are also permissions, extended attributes, access control lists, etc. And then there are CoW file systems such as APFL that can optimize copying referencing the original data instead of physically copying it.

In macOS libc there's a copyfile(3) function: https://developer.apple.com/legacy/library/documentation/Dar...

Re: Node v8.5.0

#54

Post by styfle »

spankalee wrote: post #13
pitaj wrote: post #2

> add fs.copyFile and fs.copyFileSync which allows for more efficient copying of files. 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 problem isn't the .mjs extension, but the unfortunate ability to import CommonJS modules, when that can already be done via require(). 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.

I asked about the import syntax[0] and got an answer on GitHub.

[0]: https://github.com/nodejs/node/pull/14369#issuecomment-32903...

Re: Node v8.5.0

#55

Post by coldtea »

josteink wrote: post #41
coldtea wrote: post #37

Earlier quoted context omitted.

So? If they are different types, it makes sense to have different extensions (e.g. if mts implies typescript module).

> mts implies typescript module Or mpeg transport stream: https://en.m.wikipedia.org/wiki/MPEG_transport_stream

Well, they can coordinate that like we coordinate mime types.

I've chanced upon the "same extension for the same thing" as a problem maybe 2-3 times in 30+ years.

Re: Node v8.5.0

#56

Post by pitaj »

tkone wrote: post #50
thom_nic wrote: post #40

Earlier quoted context omitted.

As Larry Wall said, "Easy things should be easy." 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 * require("some-copy-packge") * do thing The first 4 steps should be unnecessary.

or just fs.createReadStream('file.txt').pipe(fs.createWriteStream('new-file.txt')) Streams are too slow you say? fs.writeFileSync('new-file.txt', fs.readFileSync('file.txt')) I've never had a problem with no explicit copy, but I am very happy it has been added...

For the first one, what about error handling? You have to handle errors by both the read and write stream, and also most people will want a callback when everything is done, so you have to handle that event, too.

Re: Node v8.5.0

#57

Post by likeclockwork »

spankalee wrote: post #13
pitaj wrote: post #2

> add fs.copyFile and fs.copyFileSync which allows for more efficient copying of files. 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 problem isn't the .mjs extension, but the unfortunate ability to import CommonJS modules, when that can already be done via require(). 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.

I think this decision is also short-sighted since ES Modules are now JS and CommonJS should be phased out over time, but now CommonJS is the default and holds the .js extension just complicating everything for short-term ease of use.

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.

Post reply on HN